Your Platform Team Owns the Model Endpoint. Nobody Owns the Orchestration Layer.

It is 9:14 on a Tuesday in a Sydney CBD tower. The platform lead opens the model gateway dashboard and sees green: auth tokens rotating, rate limits holding, cost tags landing in the right cost centre. Ten floors down, a claims product squad is staring at an agent that retried a tool call seventeen times, wrote a half-finished memory note, then escalated a customer case with the wrong jurisdiction flag. Platform says the model responded fine. Product says the endpoint was fine. Both are right. Nobody owns the layer in the middle.

Across Australian enterprises the model endpoint has become a proper platform asset. Orchestration has not. Planners, tool loops, retries, memory stores, eval hooks, and human-in-the-loop gates still get bolted on by whichever squad ships the first agent. When production drifts, the organisation has a clean RACI for the gateway and a blank page for the runtime that actually decides what the agent does.

Why endpoint ownership feels complete

Platform teams did the hard, visible work. They stood up a shared gateway with SSO, quota, logging, and spend attribution. They put model versions behind change control. They answered the board question: who owns AI infrastructure? That answer looks solid on a slide because it maps to familiar categories: network, identity, cost, observability.

From that vantage point, orchestration looks like application code. The product squad calls the endpoint, so the product squad owns whatever surrounds the call. That split worked for classic microservices. It fails for agents, because the interesting behaviour no longer lives in a deterministic handler. It lives in a loop that plans, calls tools, retries, remembers, and decides when to stop.

So the platform dashboard stays green while the agent quietly changes shape. New tools get attached in a vendor console. Retry policy moves from three attempts to thirty. A memory store starts retaining customer context the privacy review never saw. None of that shows up as a gateway incident.

What orchestration actually includes

Orchestration is not a fancy synonym for prompt engineering. It is the control plane around the model call:

• Agent runtime and planner: how steps are chosen, ordered, and truncated.
• Tool loop: which tools are available, how arguments are validated, and what happens on partial failure.
• Retry and backoff: including when retries are safe versus when they amplify bad side effects.
• Memory and state: short-term scratchpads, long-term stores, session handoff, and retention rules.
• Eval and telemetry hooks: traces that show plan steps, tool outcomes, and policy decisions, not just token counts.
• Human-in-the-loop gates: when a human must approve, how escalation is routed, and how overrides are logged.

If your organisation only has a named owner for the model URL, you do not yet own the system customers experience.

Case study: a mid-market insurer with a green gateway

Consider a mid-market Australian insurer running a claims triage agent. Platform Engineering owns the model endpoint: Azure OpenAI behind an internal gateway, with Entra auth, per-team quotas, and FinOps tags. A product squad in Melbourne owns the triage experience. They wired an open-source agent framework to call tools against the claims core, document store, and a CRM note writer.

For three months the demo looked excellent. Latency was acceptable. Gateway error rates were low. Then a quiet change landed: the planner gained a second tool that could update reserve estimates, and the retry policy was loosened after a flaky CRM outage. Nobody filed a platform ticket because the endpoint contract did not change.

Two weeks later, operations noticed duplicate reserve adjustments and inconsistent escalation notes. Incident review split along familiar lines. Platform produced gateway logs showing successful completions. Product produced screenshots of the UI. The missing artefact was an ownership map for the orchestration layer: who approved the new tool, who owned retry semantics for money-moving side effects, and who was responsible for an eval that would have caught duplicate writes.

The model was fine. The endpoint was fine. The organisation had no named owner for the loop that bound them together.

Failure modes when nobody owns it

When orchestration sits in a gap between platform and product, the same patterns repeat:

• Blame ping-pong: platform proves the model answered; product proves the UI rendered; the runtime behaviour goes unowned.
• Shadow configuration: planners, tool schemas, and memory settings live in consoles and notebooks outside change control.
• Unsafe retries: idempotency is assumed for tools that are not idempotent, especially write paths in core systems.
• Memory without a retention owner: conversational state accumulates personal information with no clear deletion or access model.
• Eval theatre: offline demos pass, production traces are thin, and nobody is accountable for behavioural regressions.
• Human gates as afterthoughts: escalation exists in a slide deck, not as an enforceable step with an owner and an audit trail.

Regulated Australian environments feel this sharply. APRA-minded controls, privacy obligations, and AFCA-ready complaint handling all assume someone can explain what the system did and why. An ownership gap in orchestration turns that explanation into archaeology.

What good ownership looks like

Good ownership does not mean platform builds every agent. It means the orchestration layer has a RACI as explicit as the gateway.

A workable split looks like this:

• Platform owns the shared agent runtime primitives: sanctioned frameworks, secret injection, tracing standards, tool-gateway patterns, retry defaults, and environment promotion paths.
• Product owns the domain agent: business tools, prompts, escalation criteria, and acceptance tests for that journey.
• Risk / security / privacy own the non-negotiables: which tool classes need dual control, what memory may retain, and what must appear in an audit pack.
• A named orchestration owner (often a platform AI or MLOps lead working with product) owns the cross-cutting contract: versioned runtime config, eval hooks, and incident runbooks for agent behaviour.

The key is the named owner. Committees are fine for policy. Production agents need a pager path for the loop, not only for the model host.

Make the contract as boring as a service charter

Write down the same things you already write for shared services: supported runtimes, required telemetry fields, approved tool-calling patterns, retention defaults, and a promotion path from sandbox to production. If a squad invents a one-off orchestrator for a high-risk journey, treat that as an exception with an expiry date, not as a quiet precedent.

Practical next steps

You do not need a two-year platform rebuild. Start with clarity.

• Inventory one production agent end to end. List planner, tools, retries, memory, eval hooks, and human gates. Put a name beside each.
• Draw the ownership gap on one page. Show what platform already owns versus what currently has no owner. Share it with product and risk in the same meeting.
• Pick a thin shared standard. Tracing fields, retry defaults for write tools, and a rule that production tool schemas live in version control.
• Add one behavioural eval gate before the next tool or planner change for that agent. Measure duplicate writes, wrong escalations, or policy misses you already care about.
• Assign an orchestration owner for ninety days. Their job is the contract and the incident path, not building every feature.

Telco, bank, and retail teams can run the same play. The domain tools differ. The ownership gap does not.

Close the gap before the next green dashboard

Model endpoints will keep looking healthy. That is the point of platform ownership. Orchestration is where agents become systems: planning, tools, retries, memory, and human judgement under load. If nobody owns that layer, production agents will drift while every dashboard you trust stays green.

If you want a clear ownership model for agent runtimes in Australian enterprise settings, talk to the team at https://trufyre.ai. Start with one agent, one RACI, and one contract for the loop. The gateway can stay boring. The orchestration layer should stop being nobody's problem.