Throughput is a property of the platform, not the model.
A faster model gives you one agent going faster. Parallel governed execution — many agents running many paths at once, safely — is something only a platform provides. Identity, sandboxes, gates and observability deliver that. Benchmarks do not.
Your agents are not underperforming. They were never onboarded.
Imagine hiring someone exceptional, skipping their onboarding entirely, then wondering weeks later why their work is full of strange conclusions. At least that hire landed in a world built for humans. Your agents get documentation written for a person who does not exist, interfaces a machine cannot consume, and guardrails held as tribal knowledge in three colleagues' heads.
What a platform actually is
The onboarding analogy and the platform-as-product framing are from Weave Intelligence's Stop wasting tokens. Build a platform, by Kaspar von Grünberg.
The SDLC does not disappear. It becomes the harness.
This is the part most organisations miss. The deterministic infrastructure platform teams have built for years — CI/CD, policy gates, identity, security scanning — is precisely what makes probabilistic agents safe to operate at enterprise scale. Reach for agents first and platform second, and you spend the next two years retrofitting controls you skipped.
An honest caveat
This reference shape is intended for enterprises with meaningful estate sizes. If your instinct is that it feels like overkill, you are probably right, and you should ignore it. Over-automation hurts productivity too. And if you do not yet have a good IDP, an AEP is the wrong project — clean foundations come first, and we will tell you so before invoicing you.
Three layers. One of them never changes.
Tooling and path specifications swap per domain — a payments team and a claims team need different tools and different paths. Agent infrastructure does not. That invariance is the whole thesis: one base platform, many domains.
Harness — how a single agent works
Execution
Orchestration, gateways and routers, and the runtime sandbox the agent works inside. Sandboxing matters more than it sounds: parallel agent runs that share a workspace collide, and this is where a runaway agent is either contained or is not.
Context
Service graph and ontology, search and retrieval, memory and state. This is where the Domain Context Engine plugs in. Agents without sufficient information do not fail loudly — they proceed on incomplete assumptions.
Capability
Protocols, tool gateways, contracts and registries. Most of an existing platform's capability estate carries over here; mature infrastructure paths are simply exposed for agents to call.
Evaluation
Agent-output evals, goldens, rubrics, replay and change-safety gates. Eval frameworks are the new test frameworks, and they are what separates a platform an organisation can trust from one it can only hope works.
Governance — fleet-wide, never per agent
Identity
Workload identity alongside human identity, plus secrets. Agents are another kind of user: credentialed, scope-bounded, budget-constrained, egress-controlled. Built per agent, this produces an estate nobody can audit.
Agent security
Output guardrails, compliance posture, DLP and allowlists. Distinct from the security plane above, which scans code — this governs what an agent is permitted to emit.
Agent observability
Traces and telemetry, agent-specific signals, audit and cost attribution. Also distinct from application observability: this watches the agents, and at level 3 it is what triggers work.
Agent Infrastructure as Code
Platform engineers who already practise infrastructure as code will recognise the pattern immediately: same discipline, expanded scope. Agent identity bindings, policy bundles, eval suites, sandbox definitions and path specifications all live in version control, get reviewed like production code, and can be rebuilt from scratch. Without it there is no recoverability, no auditability, and no honest answer to “what changed last Tuesday”.
domain: payments
bounded_context: payments.core
context_engine:
substrate: supermemory # hindsight for self-hosted, cognee for doc-heavy
ontology: ontologies/payments.ttl
provenance: required
retrieval_scope: bounded_context.payments
golden_questions: evals/context/payments.golden.yaml
agents:
manifest: apm.yml # pinned, hash-verified
workspace: ephemeral-per-session
budget:
tokens_per_session: 400_000
usd_per_accepted_change: 12
identity:
provider: vault
workload_identity: spiffe://acme/payments/agent/{agent_id}
token_ttl: 15m
scopes: [repo:payments/*, ci:read, deploy:staging]
guardian:
endpoint: https://guardian.acme.internal/acs
policy_bundle: policies/payments@v4.1.0
failure_posture: deny
evaluation:
suites: [evals/unit, evals/rubrics, evals/replay]
promotion_threshold: 0.92
observability:
otel_endpoint: https://otel.acme.internal
ocsf: true
cost_attribution: [domain, agent_id, path]The three-layer reference shape, the five planes, the harness / governance / models split and the Agent Infrastructure as Code practice are from Weave Intelligence's What is an Agentic Engineering Platform? and From IDP to AEP, by Kaspar von Grünberg. Vendor names in our configuration examples are illustrative of the categories, not endorsements.
A platform without domain context is infrastructure with a nicer API.
Most platform teams are not building for an average developer, because there is no such person. An ML engineer needs GPU orchestration; a payments team faces compliance constraints; a front-end developer wants to ship today. Platform domains are what you build with. Business domains are who you build for. Confusing the two is how platforms get built and never adopted.
Why this matters more with agents, not less
Non-deterministic systems need deterministic architectural foundations, and agents need domain-specific guardrails to stop them making changes that violate domain constraints they were never told about. As code generation approaches zero cost, the value moves to quality assurance, integration, and knowing which constraints are inviolable. That knowledge is domain knowledge, and it has to be written down somewhere an agent can read it.
This is exactly what a Domain Context Engine is for, and why every PhaiAI agent is wired into one rather than being handed raw repository access and optimism.
The kitchen analogy
Platform domains are ingredients: flour, eggs, butter. Business domains are cuisines: Italian, Japanese, Mexican. Same ingredients, combined and presented completely differently depending on context. Handing a developer raw Kubernetes abstractions is handing someone flour and wishing them luck.
Start with a minimum viable platform. Always.
The most common reason platform programmes fail is starting too broad — too many users, too many problems, all at once. We do the opposite, and we treat the platform as a product that is never finished rather than a project that gets handed over and rots.
- 012 weeks
Assess
Locate the organisation on the four-level model against one real value stream. Mark every path as probabilistic, deterministic or hybrid. Name where the definition of done is unwritten. Report honestly, including when the answer is 'fix the IDP first'.
- 026–10 weeks
Minimum viable platform
One bounded context, one Domain Context Engine, one hybrid path end to end with real gates and a real Guardian. A handful of engineers codifying a handful of paths — proving value before defending a budget.
- 03ongoing
Harden
Agent Infrastructure as Code for everything: identity bindings, policy bundles, eval suites, sandbox definitions. Versioned, reviewed and recoverable, because 'it works on the platform lead's laptop' is not a platform.
- 04quarterly
Scale by domain
Extract the patterns that transferred, keep the ones that were genuinely domain-specific, and onboard the next domain onto the same agent infrastructure with its own tooling and its own dialect of the paths.
Is your platform ready to run agents safely?
We will trace one value stream with you, map it against the three-layer reference shape, and tell you which planes exist, which are assumed, and which are being held together by one engineer who has not taken leave in a year.