From agent dashboard to operating model

The observability platform shows rising latency and a jump in tool failures. The evaluation dashboard shows more unsupported claims. The cost report shows spend climbing. Everybody can see the problem. Nobody is sure who must act.

That is not a tooling failure. It is an operating-model failure.

Production agents cross boundaries that conventional applications usually keep apart. They use data, choose tools, generate content, make recommendations and sometimes take actions. Ownership has to cover the whole service, not only the model endpoint. The earlier parts of this series built the evidence: the cost receipt, the trace, the coverage line, governed memory, the tool record and the scorecard. This part is about the people who use it.

Weaverbird Agri is fictional, and its systems and figures are illustrative. By now Weaverbird has two agents in production. Scout writes market-research briefs for the commercial team. Depot Desk answers dealer queries and drafts credit notes for a person to approve. Both are run by a four-person digital desk, on a platform run by group IT. The CFO approves the monthly AI budget, and wants to know who owns what before approving a third agent.

The production ownership map

One person may hold several roles in a small team. The responsibilities still exist, and every one of them needs a name next to it.

Weaverbird's map, by role:

• The CFO sponsors the programme and holds the overall AI budget.
• The Head of Commercial owns Scout's business outcome: whether the briefs are worth R103.60 each to the people reading them.
• The Head of Credit Control owns Depot Desk's credit authority: the R5,000 approval threshold, who approves above it, and what Depot Desk may never do.
• Group IT's platform team owns the gateway, the approved models and the routing between them.
• The data team owns the price history store and the memory policy, including what Depot Desk may remember about a dealer and for how long.
• The digital desk owns agent behaviour and evaluation: the instructions, the golden sets and the scorecards.

Writing this down took an afternoon. It answered, in advance, every "who decides?" question the earlier incidents had raised.

A practical team structure

The agent product team owns the use case, the user experience, the workflow, the instructions, the evaluation and the measurable outcome. It needs domain knowledge, engineering and someone who can make product decisions.

The AI platform team provides approved model access, gateway patterns, identity, telemetry, policy integration, evaluation services and reusable deployment controls. Its job is to make the safe path easier than a bespoke integration.

Risk and security partners define boundaries, review consequential use cases and maintain the policy framework. They should be involved early enough to shape the design, not only to approve it at the end.

Service operations runs incident, problem, change and continuity processes. Agent incidents need run evidence, model and prompt versions, tool status, policy decisions and the list of affected users, which is exactly what the evidence layer provides.

Feedback runs back to all of them. Evidence from production should reach the business owner as outcomes, the platform team as reliability and cost, and the risk partners as policy decisions and exceptions.

The agent change record

An agent's behaviour can change when any of these change:

• the model or model version;
• system instructions or prompt templates;
• the tool catalogue, a tool's schema or its provider;
• a knowledge source or the memory policy;
• the retrieval configuration;
• an evaluation rubric or threshold;
• a policy rule;
• orchestration code;
• the user interface or an approval step.

A change record should identify the component, the reason, the owner, the test evidence, the approval, the rollout plan and the rollback path.

Note the first item. A provider can update a model behind the same name, so behaviour can change when your own code has not. That happened to Scout. After a provider-side model update, the online evaluation from Part 6 showed the citation rate dropping, and the commercial team noticed briefs had become more confident in tone with fewer hedges. Nobody at Weaverbird had changed anything. Because the platform team records the model version in every trace, the change record could name the cause within a day. Routing went back to the pinned version, the golden set was re-run against the updated model, and the update was accepted two weeks later with an adjusted instruction. Without the record, the team would have spent that fortnight arguing about whether anything had changed at all.

Incident response for agents

An agent incident may involve:

• harmful or materially false output;
• an unauthorised action;
• data exposure;
• memory leaking across users or tenants;
• a compromised tool;
• abnormal cost or a runaway loop;
• systematic evaluation failure;
• missing or altered audit evidence.

The playbook should answer:

1. How can the affected agent, tool or model be disabled quickly?
2. Can pending actions be stopped or reversed?
3. Which users, tasks and records were affected?
4. Which exact versions and policies were active?
5. Is the trace complete and trustworthy?
6. Who decides whether external notification is required?
7. How are corrected outputs issued?
8. What prevents recurrence?

The sixth question has a specific South African edge. If an incident involves personal information being accessed or acquired by someone unauthorised, POPIA's security compromise notification duties may apply, and that decision belongs to a named person with legal and privacy advice, not to whoever happens to be on call. Write that name into the playbook before you need it.

Service objectives need quality and control measures

Availability still matters, but "the endpoint responded" is not enough. Consider a balanced set of objectives:

• technical availability;
• end-to-end task completion;
• quality and groundedness;
• evidence completeness;
• policy enforcement;
• time to human escalation;
• cost per successful outcome;
• recovery and rollback time;
• correctness of data and memory.

Some of these are probabilistic and need sampling. Say how each one is measured rather than implying a precision you do not have.

A shared reference architecture

The series has described the evidence layer one capability at a time. Here is how the pieces fit together.

Evidence is not one database

The evidence layer is a logical capability, not a product and not a single store. Operational telemetry, tamper-resistant audit records, cost data, evaluation datasets and business outcomes may live in different systems, with different owners and retention rules. They should: an engineer debugging latency does not need access to a dealer's personal information, and a finance analyst reconciling invoices does not need full prompts.

The common requirement is correlation. A task identifier should connect the business request, the execution trace, the cost receipt, the evaluation result, the policy decision and the final outcome, without forcing every sensitive payload into one unrestricted store. The OpenTelemetry semantic conventions for generative AI, which define agent spans such as invoke_agent and execute_tool, are a sensible common vocabulary for the telemetry part of this, provided you remember they are still marked as in development and pin the version you implement.

A 90-day adoption path

Days 1 to 30: establish visibility. Choose one bounded use case. Define the business outcome and the risk class. Create the minimum evidence contract. Instrument model, tool, memory and policy spans. Tag cost by task, product and tenant. Record the current human effort and baseline quality, or you will never know whether the agent improved anything.

Days 31 to 60: establish judgement and control. Build an initial golden set. Add deterministic and policy checks. Calibrate model judges against human review. Define release, block and escalation thresholds. Add budgets, iteration limits and circuit breakers. Test tool failure, missing evidence and unsafe retries on purpose.

Days 61 to 90: establish operations. Name the business, product, platform, data and service owners. Write incident and rollback procedures. Reconcile cost evidence with provider invoices. Run a shadow release, then a canary. Review outcomes and correction rates. Record the go-live decision and the risks that remain open.

This is the plan Weaverbird now uses for its third agent, a stock-transfer assistant for depot managers. It is shorter than the path Scout and Depot Desk took, because the platform, the gateway policies and the evidence contract already exist. That is the real return on the first two agents: not only what they do, but how much cheaper they make the next one to run safely.

A condensed implementation checklist

Discovery

• Define the business task and intended outcome.
• Classify the impact if the agent is wrong, late, unavailable or unauthorised.
• List every model, tool, memory store and external provider, with data classes and processing regions.
• Separate read, write, communication, financial and destructive actions.

Evidence and cost

• Define trace, task, session and tenant identifiers and the minimum evidence contract.
• Version prompts, workflows, models, tools and policies.
• Decide when payload content is captured, redacted or excluded, and set sampling and retention.
• Meter model, tool, memory, platform and evaluation usage, and include human review in unit cost.
• Reconcile internal measurements with provider invoices.

Evaluation and security

• Build a representative golden set, including dependency failure and incomplete evidence.
• Calibrate model judges against human decisions, and define which failures block, warn or escalate.
• Use short-lived, least-authority credentials and allowlist approved tools and versions.
• Govern memory provenance, permissions and deletion; test prompt injection and memory poisoning.
• Maintain emergency disable and revocation controls.

Operations

• Assign an owner to every alert and exception.
• Create incident, rollback and correction procedures.
• Record changes that may alter behaviour, including provider-side model updates.
• Review outcomes, corrections and residual risk after go-live.

The production-readiness questions

Before go-live, ask:

1. Can we reconstruct each material decision and action?
2. Do we know when evidence was missing or a tool failed?
3. Are quality thresholds tied to the risk of this use case?
4. Can the agent spend or act beyond an approved limit?
5. Does every tool enforce least authority?
6. Can memory be inspected, corrected and deleted?
7. Are evaluations representative and versioned?
8. Can the service fail safely?
9. Does an accountable person own every critical alert and exception?
10. Can we measure value after including human and platform cost?

If several answers are "no", the right response is not necessarily to cancel the agent. Reduce its authority, narrow its scope, increase review and collect better evidence until the risk is understood. That is how Depot Desk started: drafting only, with every credit note approved by a person.

The short version

A dashboard has no accountability. Every domain of a production agent needs a named owner.

Record every change that can alter behaviour. Including the ones your provider makes.

Plan the incident before it happens. Including who decides on notification.

Correlate evidence; do not centralise it. One task identifier, many appropriately protected stores.

Production readiness is operability. It is the ability to operate, investigate and improve the agent under real conditions, not the ability to complete one successful demonstration.

That completes the series. It started from Sean Chen's walkthrough, discussed in Part 1, whose beginner model holds up well: observability is the camera, evaluation is the referee. Production adds the receipt, the rules and the people. An organisation that can say what its agent did, whether it was good enough, what it cost, what authority it used and who owns the outcome has an operable service. One that cannot still has a demonstration, however polished.

Start again from Part 1, or see every part on the series page. For what happens after go-live on a specific platform, see production begins after deployment, and for a broader catalogue of production concepts, the agentic AI production field guide.

How CloudNala can help

We run agent evidence reviews: checking an agent, or a portfolio of them, against the ownership map, change record, incident playbook and production-readiness questions in this series, then turning the gaps into a 90-day plan your teams can execute. For organisations about to build their first production agent, we design the evidence contract, the gateway policies and the evaluation approach up front, so the second and third agents are cheaper and safer to run than the first.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an Agent Evidence Review or write to us at consult@cloudnala.co.za