Back to portfolio
00 The platform

Production agents need platform mechanics, not just prompts.

A prototype agent can be useful with a prompt, a few tools, and a friendly user. A production agent platform needs resumable state, consistent identity, bounded tool execution, review points, observability, and a way for teams to add domain behavior without forking the runtime.

Before
Prototype gravity
each workflow solves state differently
safety and audit drift by entry point
handoffs lose context
needed one harness
After
Shared gateway
one runtime path
actions gated at execution time
domain behavior composes above it
01 Constraints

The hard parts were around the agent.

Runtime

State must survive normal failure

Long-running work needs to resume across pauses, approvals, restarts, and non-sticky routing.

Safety

Conversation access is not action access

Sensitive tools need checks at the moment they execute, with denial and audit as first-class paths.

Adoption

Domain teams need a repeatable pattern

Teams should vary workflow knowledge without rebuilding the gateway mechanics.

02 Gateway shape

Keep clients thin. Put common behavior in one runtime.

Different clients can enter through different adapters, but the runtime should receive a normalized request shape and handle state, streaming, tool calls, safety checks, and audit events consistently.

  • Normalize entry. Attach identity, source, context, and response shape before agent execution.
  • Resume state. Load the active conversation and checkpoint so work can continue after interruptions.
  • Run domain behavior. Select the relevant workflow instructions and tools without forking platform code.
EntryWeb, chat, service, or agent-client request.
GatewayNormalize identity, context, state, streaming, and audit.
AgentUse domain-specific instructions and tool contracts.
ActionEvaluate permissions, execute or deny, and record the result.
03 Tool safety

Gate the action, not just the conversation.

If people can discover what agents can do, some requests will reach tools the caller cannot use. Treating denial as an ordinary product path made the system safer and more usable. The gateway could hand the user to an authz agent that investigated the failed action and explained what approval path was needed.

Policy

Check at execution time

The model can propose an action, but the gateway decides whether the caller may run it.

Authz agent

Turn denial into a workflow

A helper agent could inspect the request, identify likely access gaps, and prepare the user for the right approval path.

Boundary

No self-approval

The agent could advise and route. A sensitive grant still needed a separate human or system approval boundary.

04 Collaboration

Shared context made handoffs part of the workflow.

Operational work often starts with one person and finishes with another. The gateway treated collaboration as a runtime concern: preserve the shared context, let a second person catch up, and keep new events attached to the same work thread.

  • Private by default. A solo thread stayed scoped to the caller unless collaboration was explicitly requested.
  • Shared when needed. A collaborative thread let another user join the same context instead of asking for a copy-paste recap.
  • Catch-up plus live work. Joiners could read prior events and then follow new progress as the agent continued.
StartOne user begins an investigation or operational change with an agent.
ShareThe user switches from private work to a shared context.
JoinAnother person catches up from prior events and continues from the same state.
ContinueThe gateway keeps state, audit, and live progress attached to the shared thread.
05 Lessons

The durable abstraction is the harness.

Through-line Agents can differ in workflow and domain knowledge, but they should not differ in how they handle state, tool safety, audit, or rollout.
< > advance
1/6