Who Owns the Agent? The Team Structure Question
Prompts need domain expertise; tools need engineering; evals are specification. That split doesn't match team boundaries, which is why agent ownership goes ambiguous — and ambiguous ownership shows up as quality nobody watches.
An agent in production needs prompts maintained, tools built, evals curated, incidents handled, quality assessed, and cost watched. Those activities belong to different existing functions, which is why agent ownership tends to be ambiguous — and ambiguous ownership shows up as slow iteration, prompts nobody dares change, and quality problems that stay unowned.
The work, and who's naturally suited
Prompt maintenance. Needs domain expertise more than engineering. The person who knows what a good support response looks like writes better constraint language than the person who knows the codebase.
Tool development. Ordinary engineering, on the team owning the underlying system.
Eval curation. Sits awkwardly — it's specification, so domain people should define the cases, but running and maintaining the harness is engineering.
Quality assessment. Domain expertise again. Whether an output is good is not an engineering question.
Incident response. Engineering, but incidents often are prompt or tool-description problems, so the on-call needs the ability to change those.
Cost and performance. Engineering, with a product decision about acceptable trade-offs.
Split it purely by function and you get a system where every change crosses a team boundary. Give it entirely to one team and half the work is done by people without the right expertise.
Three structures
Embedded — the agent is owned by the product team it serves, with an engineer who handles the technical side. Fast iteration, close to the domain. Struggles when a second team builds one and both solve the same infrastructure problems independently.
Platform plus product — a platform team owns the loop, tracing, evals, deployment, and guardrails; product teams own their prompts, tools, and cases. Scales well once several agents exist. Fails when the platform becomes a bottleneck for changes product teams need urgently — the platform must ship capabilities, not approve changes.
Central agent team — one team owns all agents. Deep expertise concentrated, consistent practices. But they're never the domain experts for every domain, and they become a queue. Reasonable early, when there's one agent and nobody knows how to build them yet; a liability once there are five.
→ The common trajectory: central team first, platform-plus-product once there are three or four agents. The mistake is staying central too long, because the queue is invisible to the team that is the queue.
What must be decided regardless
Who can change a prompt, and how fast? If it needs a full engineering release cycle, iteration will be too slow and prompts will accumulate rather than improve. If it needs no review, behavior changes ship unreviewed. The workable answer: domain experts propose, review is required, deployment is independent of code releases.
Who's on call, and what can they change? Someone paged for an agent incident needs authority to roll back a prompt, disable a tool, or flip a kill switch. On-call without that authority is a relay.
Who owns quality, with a number? ✅ Someone must be accountable for a specific measure — completion rate, escalation rate, acted-on rate — and have the ability to affect it. Unowned quality drifts, and the drift is slow enough that nobody notices until it's large.
Who owns cost? Same argument. Cost per completed task needs an owner, because it rises through many small decisions and is nobody's emergency until it's a big number.
⚠️ The failure mode to watch
The one that recurs: engineering owns the agent, domain experts are "consulted," and prompts are written by engineers guessing at domain judgment. It produces agents that are technically sound and subtly wrong in ways only a practitioner notices — and the practitioners' feedback arrives as complaints rather than as edits, which is a much lossier channel.
The inverse also happens: domain experts own prompts with no engineering support, and the system accumulates prompt patches for problems that should have been fixed in tools or code.
Both are fixed by the same thing — a workflow where domain experts edit prompts and cases directly, with engineering review and engineering owning everything below the prompt layer.
The takeaway
Agent work splits along an expertise line that doesn't match team boundaries: prompts, evals, and quality need domain knowledge; tools, loop, and infrastructure need engineering. Structure so domain experts can propose prompt and case changes directly, engineering reviews and owns the layers below, and on-call has real authority to change behavior. Then name an owner for quality and an owner for cost, each with a number — because those are the two things that degrade quietly when nobody's accountable.