There is a widening gap between an agent that works with company data and internal employees, and one that has to also interact directly with customers, vendors, and employees at other companies.

The first usually lives in a closed world:

known sources → analysis → defined output

Maybe it reads a database and produces a report. Maybe it reviews documents and extracts structured data. The work can be difficult, but the boundaries are legible. You know what enters the system, what should leave it, and how to evaluate the result. Risks are generally low because mistakes are contained inside a defined internal blast radius that does not affect external relationships.

The Problem

An operational agent lives in an open world.

I've been building one for a client that runs inside the inbox of a lighting agency. It talks to customers, factories, distributors, and the company's managing director across several countries.

Any email could be an RFQ, a technical question, a discount request, a project registration, a channel conflict, a complaint, a suspicious attachment, or two outside parties talking while the company happens to be copied.

The agent has to reconstruct the situation from incomplete information: the sender, thread history, attachments, prior quotations, CRM records, brand rules, commercial relationships, and instructions learned from the operator.

But while the input space is almost unlimited, the valid output space is extremely narrow.

A response must go to the right people, on the right thread, with the right history, tone, timing, attachments, pricing authority, and internal context removed.

A perfectly written email sent on the wrong thread is a failure.

A correct quotation that exposes the factory's discount is a failure.

A useful answer that bypasses the person who owns the relationship is a failure.

And unlike an analytical artifact, an email to a real customer cannot be rolled back.

This is what makes production autonomy so difficult.

Models can reason through edge cases. The problem is that a company cannot accept "usually" when the failure involves money, confidentiality, reputation, or a relationship built over ten years.

If an agent takes hundreds of actions, a rare edge case becomes a normal operating event.

Mitigation

So the engineering work moves beyond just context/prompting. You have to encode how the company itself works.

The action surface must stay narrow: open-world inputs flow through company architecture and an action boundary into a small set of valid outputs

For this agent, identity and hard boundaries live in one file. Procedures live in workflow-specific skills. Brand facts live separately. The mailbox acts as the queue and state machine. Every action receives an outcome label. Sensitive decisions enter a typed approval queue. Sends have duplicate guards. External audiences are separated by hard information walls. Every run writes an audit log.

The human remains inside the architecture, but not as someone watching every click.

They own the decisions where authority, relationships, or irreversible risk matter. The agent handles the repeatable work around those decisions and brings the operator a prepared decision surface when it reaches the boundary.

This is the part I think most agent demos miss.

The goal is not to enumerate every possible edge case. You cannot.

The goal is to design the system so unfamiliar cases have safe places to go: bounded permissions, explicit blockers, typed escalation, evidence before action, deterministic delivery, audit trails, and a real stop mechanism.

The model supplies the reasoning and the surrounding architecture decides when that reasoning is allowed to become action.

That is a very different engineering problem from building an agent that turns known data into a known artifact. It sits somewhere between software engineering, organizational design, product management, security, and operations. Any naming suggestions for this?

You are encoding how a company makes decisions, who carries authority, what each person is allowed to know, and how the system should behave when reality produces something nobody anticipated.

That may be the hardest and most interesting category of software I've worked on.