The Agent Triad, Re-stated for Modern Agent Systems

The diagram presents the Agent Triad as three complementary roles connected through a shared meaning layer – represented by a central Knowledge Graph – that provides context and governance. The Sensor (Observe) detects change by polling, listening, or watching and emits normalized events for downstream interpretation. The Controller (Orient + Decide) uses the knowledge graph to apply context and policy, analyze, and choose actions, and it can coordinate with other Controllers to form agent societies. The Handler/Keeper (Act/Maintain) turns decisions into bounded outcomes by executing actions and managing state, feeding actions and updates back into the knowledge graph to refresh context for the next cycle. The baseline icons reinforce an architectural boundary: agent-to-agent coordination is message-driven, while execution often relies on method-oriented services/tools, completing a loop from sensing to governed decision to action and durable state.

The Triad roles in modern terms

1) Sensor Agent (Observe)

Purpose: Convert environmental change into actionable signals.

A “Sensor” is broader than “Monitor.” Monitoring implies polling; sensing includes polling and being told (subscription/notification). A Sensor can therefore take multiple shapes:

• Poller: periodically checks for change (data drift, new records, delta queries).

• Listener: receives notifications or events (webhooks, message buses, CDC streams).

• Watcher: tracks state changes and emits normalized events (file watchers, log tailers).

What the Sensor outputs is the key: not raw data dumps, but events with meaning: typed signals that downstream agents can interpret consistently. The Sensor’s job ends when it can reliably say: “something happened, and here is what kind of thing it was.”

In modern agent stacks, the Sensor role often lives at the edge: ingestion adapters, triggers, connectors, and observability hooks.

In “agentic AI” language: the Sensor provides the observations that feed the loop.

2) Controller Agent (Orient + Decide)

Purpose: Interpret the signal in context, choose a course of action, and coordinate execution.

The Controller is the Triad’s “center of gravity.” It does two things that must not be conflated:

1. Orient: build the situational frame needed to interpret the signal correctly.

2. Decide: pick the next action(s) given goals, constraints, and policy.

This is where the Triad explicitly absorbs the most important part of OODA loop that modern agent conversations often under-emphasize: Orient is not optional. In the thesis’s OODA analysis, the Orient phase is where gross data becomes intelligence yield; and where the “dangerous shortcut” appears: pushing unevaluated, raw data directly into decision-making. That shortcut accelerates the cycle but pollutes actionable intelligence and ultimately slows the effective decision rate.

So, the Controller’s core value is preventing the dangerous shortcut by insisting on orientation – contextualization, validation, quality control, and policy gating – before action.

Controllers coordinate with Controllers: societies

A single Controller can route work to its own Handlers, but a more powerful pattern emerges when Controllers coordinate with other Controllers. This is how “agent societies” form:

• Horizontal coordination: peer Controllers negotiate or share partial context (e.g., intel Controller ↔ logistics Controller).

• Vertical coordination: supervisor Controller delegates to specialist Controllers (planner/controller-of-controllers).

• Federation: Controllers maintain local autonomy while exchanging messages through a shared protocol and shared semantics.

In contemporary terms, this is the difference between:

• one agent calling tools, and

• a multi-controller system that can distribute cognition and governance across domains.

3) Handler Agent (Act) — or Keeper Agent (Persist + Maintain)

Purpose: Perform bounded work safely; produce effects; report results.

Handlers are where intent becomes impact. The Handler should be bounded, testable, and auditable. That usually means:

• deterministic transformations (parse, extract, normalize)

• tool operations (query, write, notify, execute)

• side effects in external systems (tickets, messages, database updates)

A Keeper is a specialization of the Handler role where the primary “action” is maintaining state: curating memory, updating a context store, preserving provenance, and keeping the operational picture coherent over time. In today’s systems, “Keeper” maps naturally to:

• knowledge base / knowledge graph updates

• provenance capture and lineage

• state checkpointing and durable memory (episodic + semantic)

So, the Triad’s third role is best described as:

Handler = do the thing

Keeper = keep the meaning of the thing

Most real systems need both; whether you name the role Handler or Keeper depends on whether “execution” or “context continuity” is the dominant responsibility.

The Orient layer: why knowledge graphs belong in the Triad

If the Controller is responsible for Orient, it needs a substrate that can hold rich context and enforce constraints. This is where knowledge graphs (and the thesis’s semantic web KB framing) become more than “storage.” They become the orientation engine.

A knowledge graph provides three capabilities that directly strengthen Orient:

1. Context enrichment (background intelligence)
   The Controller can interpret an event relative to prior facts, relationships, and doctrine:
   “What is this entity? What does it relate to? What’s changed? What else is implicated?”

2. Governance and policy constraints
   Orientation isn’t merely “understanding”—it’s also “what is allowed.”
   A KG can encode: permissible actions, required approvals, confidence thresholds, and domain rules.

3. Quality control and validation
   The thesis’s Orient-phase dynamics highlight how error fraction and analysis delay reduce intelligence yield. A KG can reduce these by enforcing schema/ontology constraints, enabling consistency checks, and capturing provenance so decisions can be defended.

Net effect: the knowledge graph is how the Controller avoids the dangerous shortcut. It becomes the mechanism that turns raw observation into governed, contextualized intent.

Messages vs methods: why the Triad is naturally message-first

A modern agent architecture needs a clean distinction between agents and services. The original CoABS (Control of Agent Based Systems) design captured an enduring boundary:

• Services are method-oriented: you invoke known operations (request/response).

• Agents are message-oriented: you send messages to an addressable entity; the receiver chooses how/when to act.

That distinction matters because it delivers four properties the Triad depends on:

1. Low coupling
   If agents communicate via messages, the sender doesn’t need tight knowledge of the receiver’s method signatures, state model, or timing.

2. Asynchrony and resilience
   Message interaction tolerates latency, partial failure, offline recipients, retries, and eventual processing.

3. Scalable societies
   When controllers coordinate with controllers, you want publish/subscribe, fan-out, routing, and broadcast behaviors that are awkward in pure method-call designs.

4. Clear boundaries for “tooling”
   The Handler can still call services method-style (tools/APIs), but the agent-to-agent fabric stays message-first.

This is how you get both: fast deterministic services and adaptive distributed agency.

A clean modern phrasing is:

• Agents message each other; Handlers call services.

• Messages keep the society loosely coupled; methods let execution be precise.

The Agent Triad pattern: the stand-alone statement

Put together, the modern Triad can be stated simply:

The Agent Triad is a design pattern for governed autonomy that separates sensing, orientation-driven control, and bounded execution.

A Sensor detects change and emits meaningful events. A Controller orients those events using context and policy (often via a knowledge graph), decides what to do, and coordinates with other Controllers to form agent societies. A Handler/Keeper performs bounded actions and/or maintains durable context, reporting results back through the message fabric.

This is why the Triad scales across eras:

• In 2003, it organized distributed agents over message middleware.

• In 2026, it organizes LLM-capable controllers over tools and knowledge graphs, and without collapsing governance.

A final practical consequence

The Triad gives you a stable answer to the question “what is an agent system?”:

• If everything is a tool call, you have a workflow.

• If everything is a chat loop, you have a demo.

• If you can clearly separate Sensor, Controller (Orient + Decide), and Handler/Keeper, and connect them with message-first coordination plus a knowledge graph for orientation and governance, you have an agent architecture that can grow into a society—without losing control of meaning, safety, and accountability.