Agent Framework

Built inside the R&D organization of a large technology company, the framework is the base layer on which several teams build their own agents. It runs agents powered by large language models next to agents powered by specialized engines, and it was designed from the first commit for the two things a demo never needs: governance and observability.

The problem

Agent prototypes that work on a laptop fail in three predictable ways once real tasks arrive. A single orchestrator agent that hands out work becomes the bottleneck and the single point of failure. Rules checked after the fact let agents spend cycles planning actions that will be rejected anyway. And when something goes wrong, nobody can reconstruct what the agents saw, decided and did. The framework exists to remove those three failure modes before the first agent is written.

What we built

• Perception modules ingest and normalize inputs from APIs, documents, sensor streams and user interactions into one internal representation.
• Reasoning engines plan and execute multi-step strategies with configurable planning horizons and fallback policies, so one agent can be cautious on a risky task and fast on a routine one.
• Tool connectors come from manifests. Every external service describes its capabilities, input and output schemas, side effects and idempotency guarantees in one file. Type-safe bindings, retries, circuit breaking and authentication are generated from it, and the capability description is fed into the agent's planning context.
• Memory systems keep short-term working memory and long-term knowledge stores with retention policies set per agent.
• Execution sandboxes run each agent inside permission boundaries defined by the organization, so autonomy never exceeds policy.
• Coordination uses a shared blackboard with capability-based task claiming. Agents advertise what they can do and claim the tasks they qualify for. Conflicts are settled by priority and constraint satisfaction, not by a controller.
• Governance rules are compiled into the planning phase. The rules shape the solution space before the agent starts reasoning about actions.
• Observability gives full execution traces, decision audit logs and live monitoring across distributed deployments, all derived from one event-sourced state model.

Design decisions

No orchestrator. The first design had a controller agent delegating to workers. Under real workloads it serialized everything and failed as a unit. The blackboard model lets agents coordinate on shared goals while keeping independent execution contexts, and a new agent type can join a running workflow by announcing its capabilities, with nothing else reconfigured.

Constrain and guide, not check and block. Checking rules as pre- and post-conditions around actions treats governance as a gate. Compiling the rules into planning treats it as part of the agent's reasoning. Agents stop producing plans that would be rejected, and policy enforcement stops being a tax on throughput.

An append-only event log as the only source of truth. Synchronizing mutable state across agents produced race conditions and debugging sessions nobody could finish. With the event log, state reconstruction is deterministic, a failed run can be replayed step by step, and every decision is stored as an immutable event with its causal context. The audit trail came out of the same mechanism for free.

Tools as manifests, not code. Adding a tool means dropping in a manifest. No framework change, no custom binding code, and every agent in the deployment can discover and use the tool from that moment.

In use

A research team adds an internal service to the agents' toolbox by writing its manifest. An operations engineer takes the event stream of a run that went wrong and replays it to the exact state each agent held when it made its decision. A platform team adds a new agent type to a live workflow during the day, without stopping it. Governance owners change a policy and see it applied at planning time, not discovered at audit time.

Where it fits

Organizations that run several agent-based systems and want one governed base under them: shared tooling, shared policy, shared observability. It is built for teams that will keep adding agent types and that have to explain every decision an agent made, which is the case in regulated environments and in research alike.

What we learned

Governance belongs inside planning, not around execution. Event sourcing solved debugging, audit and behavior improvement with one design choice, which is the kind of trade that rarely comes twice. And the orchestrator pattern is the one everybody draws on the whiteboard first and regrets first.

Technology

Large language models and specialized engines behind one agent interface. A publish-subscribe communication layer with typed message channels. A shared blackboard for coordination. Event sourcing for state. Declarative tool manifests with generated type-safe bindings, retries and circuit breaking. Distributed tracing and audit logging across deployments.