The Self-Observing Enterprise

As more agents begin to operate inside an enterprise, observability stops being optional.

I first thought about this through a familiar distributed-systems analogy. Microservices forced us to get serious about traces, service maps, latency, failures and dependencies because once enough small services begin calling one another, nobody can understand the system from a static architecture diagram alone.

Agentic systems create the same problem, but the traffic is more consequential.

A service call usually tells us that one software component invoked another. An agent call may also carry a goal, context, delegated authority and a request to perform cognitive work on behalf of another actor. Knowing that the call succeeded is not enough. The enterprise increasingly needs to know who called whom, why the call was allowed, what identity was carried, what policy applied and what happened as a result.

That is what led me to build an Agent Traffic Controller.

From service observability to agent traffic control

The first version of ATC was a prototype, not a claim that the enterprise governance problem had been solved. I wanted to make agent-to-agent traffic visible and governable.

The problem was straightforward: if agents can discover and call one another through A2A, an enterprise needs a way to see and constrain that traffic. Unknown actors should not be free to appear inside the environment and begin communicating. Known actors should not automatically be allowed to call every other actor. And every consequential exchange should leave evidence.

The prototype therefore explored a control plane around A2A traffic: discovery, registration, mediated routing, identity, policy hooks, request and response inspection, and audit events.

Instead of handing one agent the raw endpoint of another, ATC could virtualize the route through a gateway. The gateway could preserve requester identity, issue a short-lived token for the target, attach an audit identifier, inspect the interaction and record the event.

Once machine actors can delegate work to one another, observability has to become authority-aware.

Who is calling whom?

The first useful question is still the simplest one: who is calling whom?

In a small demo, the answer is obvious. There may be five agents and a visible orchestrator. In a large enterprise, there may eventually be thousands of machine actors spread across business units, platforms and vendors. Some may be permanent roles. Others may be temporary worker instances created elastically for a surge in demand.

A static inventory does not tell us what the machine organization is actually doing.

I want an enterprise to be able to see the interaction topology: which agents are active, which relationships are common, which routes are unusual, which actors are creating the most traffic, where calls are being blocked, where retries or clarification loops are accumulating, and where a new relationship has appeared that nobody expected.

That starts to look less like an application dashboard and more like air-traffic control.

The analogy is useful because air-traffic control does not fly every aircraft. It creates visibility and rules for movement inside shared airspace. It knows identities and routes. It coordinates access. It detects conflicts. It can deny or redirect movement when required.

An Agent Traffic Controller plays a similar role for machine actors without becoming the orchestrator for their business work.

Allow lists before autonomy

I would start with relatively simple governance.

Which agents are recognized? Which agents are allowed to communicate? Which direction is permitted? What type of interaction is expected? Which policies apply to the request and response? What evidence must be retained?

This is deliberately more conservative than a free-form agent mesh.

Technical discovery makes it possible for one agent to find another. Enterprise governance has to decide whether that discovered relationship should exist.

The ATC prototype already explored deny-by-default ideas, identity verification, mediated routing, audit identifiers, PII and PHI inspection, response filtering and circuit-breaking. The point of those controls was not that every interaction needs to pass through one giant centralized gateway forever. The point was to make the governance requirement visible: machine-to-machine delegation needs an enforceable boundary somewhere.

Agent traffic carries more than packets

This is where agent observability differs from traditional service observability.

A trace such as service-a → service-b → 184 ms → 200 OK is useful for engineering. An agentic trace increasingly needs business and authority context as well.

A more meaningful record might say:

Renewals ABU → Contract Analysis capability → Legal ABU / Contract Reviewer → objective 8F21 → requested under delegated authority → route allowed by policy → audit evidence preserved.

That is not what the current ATC prototype fully implements. It is the direction that becomes visible when ATC is placed inside the larger Agentic Enterprise architecture.

The enterprise needs to understand not only the technical caller and target, but also the organizational meaning of the interaction.

The capability map and ATC solve different problems

This also helped me separate two layers that are easy to mix together.

The living capability map from Section 04 should answer the business discovery question: what capability do I need, and which approved part of the enterprise currently provides it?

ATC answers the traffic-governance question: is this machine actor allowed to communicate with that provider, under what identity and policy, and what happened when it did?

The ABU harness answers a third question: what does this call mean inside the end-to-end business objective I am responsible for?

Those distinctions matter because I do not want one giant control plane to become the architecture for everything.

Capability gives the route business meaning. ATC governs the machine traffic. The harness preserves the objective.

Inside one small ABU, a front office may call its own workers directly. Cross-ABU execution is where the capability layer and traffic governance become more important. A Renewals ABU should be able to request Legal Review without knowing or caring which particular agent instance performs it. The capability layer can resolve the approved provider. ATC can then govern and observe the resulting machine interaction.

Observability becomes governance

There is another difference from traditional APM.

Agent observability is not useful only after something goes wrong. The same evidence can become part of runtime governance.

If an unknown agent attempts to call a restricted provider, the system should not merely draw a red line on a dashboard. It should be able to deny the route. If an agent begins generating an unusual spike of traffic, a policy can slow or isolate it. If repeated calls trigger a sensitive-data rule, the interaction can be blocked or redacted. If a target is overloaded or behaving abnormally, traffic can be limited while the reason is preserved for audit.

That is why I prefer the traffic-control metaphor to simple observability. Visibility and control begin to converge.

The self-observing enterprise

ATC is one piece of a broader idea.

Today's enterprise already emits enormous amounts of evidence about itself: application telemetry, service-management records, portfolio data, financial metrics, project status, security events, business KPIs, architecture repositories and human reports. The problem is not absence of information. It is fragmentation.

As capabilities become more living and ABUs become more executable, some of that fragmented evidence can begin to line up around the operating model itself.

A CIO could increasingly ask:

Which capabilities are being changed right now? Which programs are responsible? Which capabilities do those programs depend on? Which ABUs are providing execution? Where is human decision work accumulating? Which cross-ABU routes are growing? Which interactions are being denied? Which capability implementations are degraded? Where is machine capacity scaling rapidly? Where does the model of the enterprise no longer match the behavior of the enterprise?

This is where MeridianCommand fits in my thinking. I originally imagined it as an evidence-backed view of capability maturity and transformation: if somebody claims that a capability is mature, show the evidence. Show the programs improving it and the dependencies around it.

In an Agentic Enterprise, that command view can become richer because the enterprise is generating runtime evidence through the same capability and machine-execution layers.

MeridianCommand does not need to become ATC. ATC can remain the traffic and governance layer. Meridian can consume evidence from ATC, capability systems, programs, KPIs and other sources to show what is changing at enterprise level.

Self-observing does not mean omniscient

I use the phrase self-observing enterprise carefully.

No enterprise will have perfect knowledge of itself. Data will remain stale. Human decisions will occur outside systems. Some dependencies will be tacit. Some machine traces will tell us what happened without telling us whether the business interpretation was correct.

The goal is not omniscience.

The goal is to reduce the distance between what the enterprise is doing and what its leaders, architects, governors and machine systems can see about that activity.

That becomes increasingly important as human execution declines. When people perform most of the work, managers learn what is happening through the people themselves. They ask questions, sit in meetings, receive escalations and accumulate organizational intuition.

When more work moves into software, that informal visibility can disappear unless it is deliberately rebuilt into the runtime.

The more autonomous the machine organization becomes, the stronger the requirement for evidence, authorization and command.

The machine organization needs a control tower

I do not think one product will become the universal control tower for every enterprise. The architecture is more likely to be assembled from several layers: capability intelligence, agent traffic control, harness telemetry, policy systems, security platforms, operational metrics and human decision records.

But the requirement itself is becoming clear to me.

An enterprise with thousands of machine workers cannot be governed through static diagrams and quarterly inventories. It needs a current view of the machine organization: who exists, who is interacting, which authority is being exercised, which outcomes are being progressed, where controls are firing and where the system is changing.

That is the difference between deploying many agents and operating an Agentic Enterprise.