Build an agentic enterprise

A water utility has one agent working. It investigates network anomalies, and the engineers trust its findings. Now the sponsors ask how to get from one agent to many without losing control. The answer has six steps. Prove one task first. Share what every agent needs. Name the owners and change how the teams work. Count the agents you buy inside vendor products. Expand only where measured results justify it. Keep improving, with a way back. This is step 7 of the seven steps on Start here.

1. Prove one task

Pick one use case with clear limits and show the result. Use the trial to learn what information, interfaces and supervision the work really needs. Do not build a general platform before you know those needs. Choose where to start has the checks for the first task.

2. Share what every agent needs

An agent platform provides seven capabilities. Five of them repeat from the first agent to the second. Build them once and share them where the needs match.

The last column names the main layer for each capability. The fourteen layers page shows the rest. Two rules hold for every agent you add. Policy is enforced outside the model. The audit trail is written where the agent cannot touch it.

Keep a specialist model or a specialist knowledge source separate where its task needs it.

3. Name the owners and change how the teams work

Name a business owner for results and a technical owner for the service. Name data owners for the evidence, and the people who handle exceptions. Agree how incidents are reported, how changes are released and how work goes back to a person.

The agent lifecycle gives each agent a sponsor and an owner. It also gives each agent a path from registration to retirement. Autonomy and learning are separate choices for each task. The autonomy contract sets both.

As the number of agents grows, the teams need a shape. How the teams are organised sets out one design. A small office writes the rules and holds the money. One platform team turns the rules into automatic checks. Three small lanes build each new pattern once, then step back.

4. Count the agents you buy

Some agents arrive inside products the enterprise buys. These are vendor-embedded agentsYour own agents and vendor-embedded agents. Agents you build run through your own gateway, so you can govern every action. Agents embedded in vendor products run on the vendor's platform, so you govern them only through its settings and the records it exports.. Agents you build run through your own gateway. Vendor-embedded agents run on the vendor's platform, and you govern them through its settings. Check what permissions, logs, cost data and controls each product exposes. Put every agent in one registryAgent registry. The official list of agents: what each is for, who owns it, what it may touch, and which version is live.Read the page, bought or built. Agents and packaged applications sets out when to wait for a vendor's agent and when to build your own.

5. Expand only on measured results

Move from one working task to related tasks. Then move to a department, then to work that crosses departments. A good pilot does not prove that a larger or riskier scope is ready.

Each step up needs the same evidence as the first. Recheck the shared supervision capacity and the cost per resolved outcome. Vendor agents draw on the same reviewers as your own. Run the use-case portfolio every quarter, with measured inputs.

6. Keep improving, with a way back

Use production evidence to decide what to change: information, instructions, tools, workflow or model. Test each change before release and keep a way to roll it back. The learning flywheel shows how. Research covers open questions that may change the design.

A worked example: the utility's second agent

The utility's second agent handles billing exceptions. It reuses the identity, the tool gateway and the audit trail built for the first agent. Its tests are new, written by billing specialists. Its risk is higher, because a bill change moves money. So a person approves every bill change in the billing system. A trained person decides anything about hardship or a payment plan. The reviewers come from the billing team, so supervision capacity is counted again for them.

Evidence and limits

This order is a suggested approach. It has not been tested as a whole programme. Each step rests on the evidence in the pages it links. The portfolio's gates, scoring and stop criteria are practitioner rules, not validated thresholds. The team design on the organisation page is a proposal. The utility in the example is illustrative, not a named deployment.

Next step

Describe each new agent with the four questions, or run the weekly checks on Operate.

Explore this topic

• The use-case portfolio: the gates, the scoring, the constraints across the set, the stop criteria and the quarterly cadence.
• The economics model: cost per resolved outcome and who pays when an agent loops.
• Vision and target state: the full research view of the agentic enterprise.