Enterprise Agentic Automation Platform

SummaryBuy the runtime,
build the governance

This is a design for an enterprise agentic automation platform and the lifecycle that governs how agents get built, shipped, operated and retired. It is deliberately framed as a platform-and-lifecycle design, not a single assistant. Use cases come first, because choosing the right first use case should drive the architecture — not the other way round.

The headline recommendation is a hybrid build: buy the runtime, build the governance. Google ADK is deployed as the agent framework and Vertex AI Agent Engine as the managed runtime, while we build our own thin layers for governance, connectors, evaluation and human-in-the-loop. Value is proven first on the highest-volume, lowest-risk use case — a customer support copilot — and a higher-autonomy responsible-gaming and AML copilot is deliberately held back as the governance showcase.

Because the client is a regulated gaming operator, responsible gaming, AML and auditability run through every layer of the design. They are not a compliance chapter bolted on at the end.

FramingApproach and assumptions

The brief deliberately leaves a number of things open and asks for reasoning as much as for conclusions. The assumptions below are stated explicitly, so that if any one of them turns out to be wrong the design can be re-derived quickly rather than quietly failing.

• No agentic platform exists yet. The core enterprise stack is assumed to be SAP, Jira, Confluence and SharePoint (strongly Microsoft), alongside a modern web and mobile presence and the public gaming portal.
• Cloud-first is acceptable within EU data residency. Vertex EU regions satisfy both GDPR and the regulator on where data physically lives. Self-hosting is reserved for cases where regulation forces it — it is not ruled out, it is simply not chosen to save time.
• Detection tooling already exists. The operator already runs Neccton (via OpenBet) for AML, fraud and responsible-gaming detection. The agentic layer complements it as a triage and analyst copilot; it does not rebuild the detection engine.
• Sensitive systems are brokered, never direct. Player data, payments and KYC are sensitive systems. Agent access is least-privilege and brokered through tools, never a direct connection.
• Team and horizon. Five to seven engineers, and six months to build the platform and prove value on one use case.

The order of the rest of the document mirrors the way I would present it: use cases first, then architecture, then lifecycle.

Part 1Four candidate use cases

Each candidate is grounded in the operator's real business as a lottery and gaming company. For each one: the problem, what the agent actually does, the systems and data it touches, its level of autonomy, and the expected value.

The callBuild the support copilot first

Of the four, the support copilot is the right first build, for four reasons:

• Highest query volume, so value shows up quickly and is easy to measure — deflection and average handling time.
• Low autonomy, small blast radius. The agent drafts, a human sends, and the worst case is a bad draft caught long before it reaches a player.
• It exercises every part of the platform once — connectors, human-in-the-loop, evaluation, observability — so the team learns the whole system on a low-risk case.
• It de-risks the platform before we take on anything with higher autonomy.

The responsible gaming and AML copilot is held as the second build. As a governance showcase and a demonstration of where AI must not act, it is ideal — but it is far too sensitive to be the first thing we ship.

How one platform adapts across autonomy levels

The brief asks how the architecture moves between a low-autonomy and a higher-autonomy use case. The two selected use cases answer that directly, on one platform:

Part 2Technical architecture

The goal is one multi-use-case platform, layered so that a request enters through any channel, is routed by the orchestration layer, answered by the cheapest capable model, and connected to source systems through a single brokered, least-privilege path. Observability and governance are cross-cutting: they wrap every layer rather than sitting as a layer of their own.

Orchestration

• Multi-agent coordination inside one process uses ADK sub-agents and workflow agents (sequential, parallel and loop) sharing session state. An LLM router picks the branch — the deterministic steps stay deterministic. This is distinct from A2A.
• Cross-team and cross-vendor coordination uses the A2A protocol, but only where an agent is exposed or consumed across a team or vendor boundary. The client's SAP environment already speaks A2A through Joule, which makes this practical rather than theoretical.
• Human-in-the-loop is a first-class step in the flow, not an afterthought. Escalation is a routing node triggered by confidence thresholds, by any action touching money, KYC or responsible gaming, or by a low eval score.
• Tools are exposed over MCP, each narrowly scoped, so the same tool is reusable across agents and independently testable.

LayerModels sized per task

Models are sized per task, not defaulted to the largest available. The platform standardises on the current Vertex line from day one, because Gemini 2.5 Flash and Flash-Lite retire on 16 October 2026.

Fallback. A controlled backup model plus a cache or templated safe answer when models or tools are unavailable, so the system degrades instead of erroring. Hosting is cloud (Vertex EU regions) for data residency; self-hosting is reserved for where regulation requires it.

Tool and connector layer

Agents never touch source systems directly. They call MCP tools that wrap existing APIs and services. The integration assumptions are stated explicitly:

• CRM, player database, payments, KYC and ticketing expose an API or service layer that we wrap; where they do not, we build a thin adapter.
• There is a single brokered, audited entry point, locked down at ingress and secured with mTLS, with no lateral calls between systems.
• Every tool holds least-privilege credentials in a secret manager — never in prompts, never in code.
• Writes to money, KYC or player state go through an idempotent, reversible command with an approval step.

Human-in-the-loop

A human is required, and the flow routes to a person, whenever:

• money moves, or KYC and account state change;
• a responsible-gaming signal is in play;
• model confidence or eval score is below threshold;
• a tool call is irreversible or high-impact;
• or the request falls outside the agent's defined scope.

The escalation carries full context, so the person can see why it was raised and act in one place.

TrustObservability and evaluation

Trusting non-deterministic systems in production requires this to be built in from day one. Every element below has been implemented in practice on a comparable enterprise assistant.

• Tracing. An OpenTelemetry span per request, agent, tool and model call, including the router's branch decision, so we know why a given path was taken. Trace IDs propagate across A2A boundaries.
• Logging. Structured logs with PII redacted before write, append-only for auditability, with retention set to GDPR and gaming record-keeping requirements.
• Eval pipeline. A golden dataset and regression suite run in CI before every release. LLM-as-judge is used, but calibrated against human labels rather than trusted blindly. Release is conditional on not dropping below baseline.
• Live monitoring. Production traffic is continuously re-scored. Guardrail metrics (refusal rate, injection detection, PII-leak flags), drift detection and tool error rates are tracked over time.
• Cost and latency. Dashboards for token spend per use case and model, p50/p95/p99 latency, cache hit rate and model mix, with budget alerts.
• Feedback. Explicit thumbs plus implicit signals — edit distance between the agent's draft and what the operator actually sent, escalation rate — feed back into the eval set.

Reliability and scaling

• Failover. A health-checked backup model and region. When a model or tool is down, the system degrades to a smaller model or a safe templated answer — not an error.
• Rate limits and concurrency. Per-tool and per-tenant quotas with queues and backpressure, so a peak (a big Eurojackpot rollover) cannot take the platform down.
• Degradation modes. Explicit levels: full agent, limited (retrieval only), and static fallback. Users always get a useful answer, never a stack trace.
• Caching. Prompt and semantic caching on repeated queries cuts both cost and latency and absorbs load spikes.

DecisionBuild vs buy vs hybrid

The decision is framed against clear criteria, not a preference for one tool. Copilot Studio has a genuine advantage in native fit on an M365 and SAP stack, and should not be dismissed lightly.

Off-the-shelf SaaS, and why it is not enough as a platform

The honest question is why not simply buy a ready-made support SaaS — Gleap, Intercom Fin, Zendesk AI — for the support copilot. For a customer chatbot on its own, that is a legitimate choice: deployment in days, tier-1 deflection with handover to a human, knowledge base, multichannel, and on enterprise plans SOC 2, GDPR and EU data residency. The cost is an order of magnitude below running our own platform, so for an isolated support use case SaaS makes economic sense. I would genuinely put it on the table at intake — quite possibly as the fastest route to value on use case one.

Where it stops being enough is the scope of this brief. What is being asked for is not a chatbot but an enterprise agentic platform across multiple use cases and a full lifecycle, at a regulated operator. Support SaaS covers customer support and feedback; it does not cover retail support tied to settlement in SAP, RG and AML triage sitting on top of Neccton, or internal operations across Confluence, Jira and SAP. Solving those with off-the-shelf products means buying several vertical SaaS tools, each with its own data-sharing surface — and still owning the integration and governance across all of them.

And for the sensitive use cases — money movement, KYC and AML, responsible-gaming intervention — I cannot hand orchestration, player data or transaction data to a third party and rely on its guardrails. The regulator and the licence conditions require that I own the audit trail, decision traceability, data residency, and the boundary where AI must not act. That is exactly the core of this brief, and it is exactly what an off-the-shelf product will not deliver across the organisation.

Part 3The agent lifecycle

Every agent moves through seven phases, from idea to retirement. Two of them — the security review, and the legal and compliance review — are hard gates that can stop a release outright.

1. Intake and design. The business proposes a use case; we scope it, set expectations, assess data and feasibility, and go to the relevant data owners to confirm whether and how a system can be connected. Approval gate before build.
2. IT and data infrastructure. At least three environments (DEV, QA, PROD), data pipelines, access to source systems, and CI/CD. Each agent's infrastructure needs are defined here.
3. IT security. Access control, secrets and credential management, and the threat surface of tool-using agents: least privilege per tool, prompt-injection defence, no excessive agency, one brokered mTLS ingress with no lateral movement, and a pen-test gate on that entry point before production.
4. Legal and compliance. GDPR (PII anonymised in logs, consent captured), responsible gaming, AML and KYC, record-keeping and auditability, and an explicit determination of where AI must not act alone. A hard gate for a regulated operator.
5. Build, test and release. Evaluation and acceptance criteria, sign-off, and a staged or canary rollout.
6. Operation and monitoring. Clear production ownership, incident handling and escalation, and monitoring for drift and quality.
7. Change and retirement. Versioning, updates, and safe decommissioning.

Hard gatesSecurity, legal and ownership

IT security

• Least-privilege access per tool; secrets in a vault, never in prompts or code.
• Prompt-injection defence: untrusted content must not be able to trigger privileged tool calls.
• No excessive agency: irreversible actions require approval, and writes are reversible.
• A single brokered ingress secured with mTLS, with no lateral movement between systems.
• A pen-test gate on that entry point before every production release.

Legal and compliance

• GDPR. PII anonymised in logs, and consent captured for chat and any personal data the user provides.
• Responsible gaming. No autonomous action that could nudge an at-risk or self-excluded player.
• AML and KYC. The agent prepares the case; a human decides and acts.
• Auditability. Immutable records and decision traceability for the regulator.

Ownership (RACI)

A simple view of ownership across the key phases. The security and legal rows are accountable for their own gate, which is why those two phases can stop a release hard.

DeliverySix months, one team

Team of five to seven. A lead, two agent and platform engineers, one integration engineer, one data and eval engineer, and one to two flexible. Security and legal are consulted partners, not headcount the AI team owns.