AI • • 8 min read

From One Agent to an Operating Layer

The second agent proves whether the first one was a pilot or reusable infrastructure. Expansion should compound context, controls, monitoring, and ownership.

Chris Fitkin
Chris Fitkin
Partner & Co-Founder

Most companies do not need more isolated AI experiments. They need a way for one production workflow to make the next workflow easier to launch.

The first useful agent often feels like the breakthrough. It proves that AI can touch real work, connect to real systems, and produce outputs people are willing to review or use. But one agent is still only one workflow. The more important question is what the company learns and reuses after that first launch.

That is why the second agent tells the truth about the first one.

If the second workflow starts from scratch, the first agent was a pilot. If the second workflow reuses context rules, permission patterns, review surfaces, evals, logging, monitoring, and ownership cadence, the company is starting to build an operating layer.

That distinction matters because enterprise AI does not scale by collecting isolated agents. It scales when each workflow strengthens the infrastructure for the next one.

McKinsey’s 2025 State of AI survey shows that AI agents are still early in enterprise scaling: 23 percent of respondents say their organizations are scaling an agentic AI system somewhere in the enterprise, while 39 percent are experimenting. Even among those scaling agents, most are doing so in one or two functions. The expansion challenge is real.

The second workflow is the strategy test

Ask what the first agent created that the second agent can reuse. If the answer is nothing, the company has a tool, not an operating layer.

What Compounds

The reusable operating layer has six parts.

First, the source-of-truth map. Once one workflow decides which systems own account status, contract terms, ticket severity, vendor records, or policy exceptions, the next workflow should not renegotiate those rules from zero.

Second, the identity and permission model. Agents should inherit a consistent model for what they may read, draft, recommend, write, and never do.

Third, the review surface. If humans approve outputs, reject outputs, explain edits, and route exceptions in a structured way, that surface can serve multiple workflows with different rubrics.

Fourth, the evaluation harness. Examples, edge cases, accepted outputs, rejected outputs, and incident cases should become test material for future changes.

Fifth, the audit event. Every workflow should log sources, model output, reviewer decision, tool call, write-back, and final status in a consistent shape.

Sixth, the operating cadence. Monthly workflow reviews, incident reviews, cost reviews, and expansion decisions should become normal business operations.

IBM’s data governance guidance supports the reusable role model behind this. Governance needs clear ownership, access rights, responsibilities, and access mechanisms such as role-based access control. NIST’s AI Risk Management Framework adds the lifecycle lens: trustworthiness has to be incorporated into design, development, use, and evaluation, not bolted on at the end.

The Operating Layer Roadmap

Operating layer expansion roadmap

First workflow

Proves value and defines the first production pattern.

Shared controls

  • Context rules
  • Permission pattern
  • Review surface
  • Evals and audit

Second workflow

Reuses the controls instead of restarting from pilot mode.

Operating cadence

Portfolio reviews turn repeated patterns into an operating layer.

The roadmap is not “launch ten agents.” It is “make each workflow cheaper, safer, and faster to launch because the operating layer gets stronger.”

From agent to operating layer

The first workflow should be designed narrowly but not as a throwaway. Make the reusable operating pieces explicit before launch.

Reusable layer: Context

First workflow should define
Source systems, field ownership, retrieval paths, evidence display, and freshness rules.
Second workflow should reuse
The same source contracts where business objects overlap.

Reusable layer: Permissions

First workflow should define
Read, draft, approve, write, and never-do boundaries for the agent.
Second workflow should reuse
Common identity patterns, role scopes, and approval gates.

Reusable layer: Review

First workflow should define
Reviewer rubric, acceptance threshold, rejection reasons, and escalation path.
Second workflow should reuse
Shared review UX and structured feedback patterns.

Reusable layer: Measurement

First workflow should define
Baseline, accepted output rate, review load, exception rate, and business metric.
Second workflow should reuse
A common value scorecard that still allows workflow-specific metrics.

Reusable layer: Operations

First workflow should define
Monitoring, cost review, incident response, owner cadence, and expansion gate.
Second workflow should reuse
A repeatable monthly AI Ops rhythm.

Expansion Without Sprawl

Expansion gets dangerous when every department gets its own agent with its own data assumptions, permission shortcuts, review habits, and success metrics.

That path creates AI sprawl. It feels fast at first because every workflow can move independently. Then the company discovers that no one can compare quality, audit actions, manage access, control spend, or reuse context across functions.

A better expansion pattern is sequence plus reuse:

  1. Pick the first workflow with measurable value and manageable risk.
  2. Build the minimum context, control, review, and measurement layer it needs.
  3. Launch narrow with human approval.
  4. Review real operating evidence.
  5. Choose the second workflow based on what can reuse the first layer.

This is slower than declaring an enterprise AI platform. It is faster than rebuilding the same debates eight times.

Launch path

This is the minimum operating sequence after the article's decision test. Do not expand the roadmap until one workflow can move through these steps with evidence.

Step 1

Map the work

Capture trigger, owner, systems, handoffs, approvals, exceptions, and baseline.

Step 2

Design control

Define context, review surface, permissions, write-back, and audit events.

Step 3

Launch narrow

Ship one workflow with a measurable outcome and visible human decision point.

Step 4

Operate and expand

Monitor quality, cost, adoption, incidents, and the next adjacent workflow.

What to Do Next

After the first workflow launches, run a post-launch reuse review.

Ask:

  • Which source rules became reusable?
  • Which permission patterns worked?
  • Which review decisions became structured data?
  • Which eval examples should enter the shared test set?
  • Which monitoring dashboard should become standard?
  • Which adjacent workflow can reuse the most of this work?

That review is the bridge from agent to operating layer.

Metacto’s bias is to start with one workflow because focus creates proof. But the first workflow should still be designed to compound. The goal is not a gallery of agents. The goal is an operating layer that makes the next agent safer, clearer, and more valuable.