Architecture

Infrastructure in operator systems serves a different purpose than in conventional software.

In traditional applications, infrastructure is primarily designed to support scalability, service boundaries, and asynchronous communication between components.

In operator systems, infrastructure exists to support the operator -> system -> environment loop.

The goal is not to maximize architectural flexibility. The goal is to enable reliable progress toward the operator's goal in a dynamic environment.

The Role of Infrastructure

The infrastructure layer is responsible for executing actions produced by the reasoning system and returning observable results.

Operator
-> Reasoning System
-> Infrastructure
-> Environment
-> Deterministic Boundary

This layer typically includes:

• automation runtimes
• task execution workers
• environment adapters
• tool interfaces
• communication channels
• state persistence

However, infrastructure should remain subordinate to the operator system.

When infrastructure decisions begin to dictate how problems must be expressed, the architecture becomes inverted.

A Common Architectural Mistake

Many systems are built starting from infrastructure primitives:

• webhooks
• message queues
• websocket streams
• event buses
• distributed workers

These patterns are useful for scaling deterministic services, but they can introduce unnecessary complexity when applied prematurely to operator systems.

For example:

Operator goal
-> Agent action
-> Webhook triggered
-> Queue event
-> Worker picks up task
-> Environment interaction

This may be appropriate in some contexts, but often it simply reflects conventional software architecture rather than the needs of the operator system.

If the task can be executed directly within the control loop, introducing asynchronous infrastructure may only add latency and complexity.

Infrastructure Should Follow the Operator Loop

A better approach is to derive infrastructure from the operator system itself.

The core loop remains:

observe -> reason -> act

Infrastructure should support this loop rather than fragment it.

For example:

Operator defines goal
-> System observes environment
-> Reasoning layer selects action
-> Infrastructure executes action
-> Environment responds
-> Boundary validates result

The infrastructure layer should make this loop easier to run and scale, not harder to express.

When Infrastructure Becomes Necessary

As operator systems scale, infrastructure becomes important in several areas:

These capabilities allow operator systems to operate reliably even as the environment changes.

Infrastructure Is Not the System

A useful mental model is:

Infrastructure executes
Reasoning decides
Operator defines intent

When infrastructure begins to encode business logic, the system becomes rigid.

The more infrastructure dictates how tasks must be expressed, the more difficult it becomes for operators to represent new goals.

This can unintentionally restrict system capability.

In extreme cases, users cannot even express the problem they are trying to solve within the architecture.

Designing Infrastructure for Operator Systems

Good infrastructure for operator systems tends to share several characteristics:

• minimal surface area
• flexible execution loops
• explicit boundaries
• observability
• environment awareness

The system should expose only the primitives necessary to interact with environments and execute actions, while supporting iterative reasoning rather than fixed workflows.

Example: Browser Automation Infrastructure

Operator
-> Reasoning System
-> Automation Runtime
-> Website Environment
-> Deterministic Boundary

The infrastructure layer might include:

• browser session management
• page interaction APIs
• environment observation tools
• DOM extraction utilities
• execution sandboxes

But these exist to support the control loop, not replace it.

The reasoning system still decides what actions to attempt.

The deterministic boundary still decides what results are acceptable.