From Message Primitives to Managed Agent Platforms

Message interfaces solve the problem of “passing a piece of context to a model and receiving a reply.” They work well for question answering, summarization, rewriting, and controlled function calls, where boundaries are clear, latency is predictable, and billing and auditing are relatively simple. But once a task requires multi-step planning, reading and writing external systems, retrying after failures, and maintaining a goal across a long session, a single request is no longer the right abstraction. A managed agent platform must answer a different set of questions: who owns the goal, who schedules the tools, who approves side effects, and how state is recovered after a failure.

1. The Two Kinds of Primitives Should Not Be Mixed

The message primitive is fundamentally about request and response: the caller submits system constraints, conversation history, and current input, and the service returns text or a structured result. The caller holds nearly all control, and with it, the full responsibility for assembling context, selecting tools, interpreting results, and deciding whether to continue.

The agent primitive delegates “accomplishing a goal” to the runtime. Within the bounds of policy, the runtime loops: understand the goal, choose the next step, invoke a tool, observe the result, update working memory, and repeat until completion, blockage, or termination. What the developer embeds is not a single reply but a reusable execution loop.

The two can coexist. Short paths should continue to use message interfaces to reduce complexity and cost; only long paths need to enter the agent runtime. If every request is upgraded to a multi-step loop, latency, cost, and unexplainable behavior are amplified. Conversely, if obviously multi-step tasks are forced into single messages, orchestration logic gets scattered across business services, making unified permission control and auditing difficult.

2. Two Integration Modes

Stateless, single-run tasks suit scenarios where the goal can be stated once and a final result is acceptable. Typical examples include: generating a change description from a ticket, summarizing the root cause of a log segment, or locating potential defect locations on a read-only code index. The caller does not need to maintain a session handle; on failure, simply retry the entire run. Such entry points should be limited in steps, tool set, and total duration to prevent unbounded expansion.

The following illustrates the control flow and is not tied to any vendor’s actual API:

run_once(
  goal,
  tools=["read_only_search", "format_report"],
  max_steps=8,
  timeout="60s"
)

Stateful, multi-turn sessions suit work where the goal may change, human confirmation is needed, or intermediate results must be referenced by later steps. Examples include: refactoring a module in phases, listing options first and then executing after confirmation, or tightening permissions incrementally across turns. A session client should explicitly hold the session identifier, working memory, authorized tools, and unfinished plan, rather than dumping all history back into the next message indiscriminately.

The choice can be guided by four questions: Is there an irreversible side effect? Can the goal be modified during execution? Do intermediate artifacts need to be reviewed by a human or downstream system? On failure, is a full redo cheaper, or is continuing from a checkpoint safer? If the first two are “yes” and the last one points to checkpoint recovery, prefer stateful sessions. If all four are “no,” prefer stateless single-run tasks.

3. What the Runtime Should Manage

Making an agentic programming or business operation capability embeddable as a library is not about wrapping another model call. It is about turning the mechanisms that recur in the loop into platform-level capabilities.

Tool contracts must be machine-readable. Each tool declares its purpose, input/output schema, whether it is read-only, whether it is idempotent, and its timeout and rate limits. The model should only see tool descriptions permitted by the current policy, not the full interface surface of the business system. Read-only retrieval and write/delete/external-notification tools must be registered separately.

Permissions should be authorized by action, not by “whether the entity is trusted.” Least privilege means: read-only by default; writes confined to workspace or tenant boundaries; and actions involving publishing, transfers, deletion, or bulk external messaging require explicit confirmation. Confirmation prompts must include the action, the target object, the impact scope, and rollback feasibility—not just a bare “continue?”

Hooks move policy out of the prompt. Pre-execution hooks can perform parameter validation, sensitive-field masking, and quota checks. Post-execution hooks can log diffs, trigger review, and write audit records. Failure hooks decide whether to retry, degrade, or escalate to human handling. When a hook fails, the default should be to deny side-effecting actions rather than allowing them through and backfilling logs later.

Working memory and checkpoints determine recoverability. Short-term memory holds the current plan, verified facts, and unresolved issues. Long-lived artifacts should be written to object storage or a business database with versioning. Each step records a summary of input, the tool name, a summary of the result, elapsed time, and the reasoning for each decision. On recovery, resume from the most recent consistent checkpoint to avoid sending duplicate notifications or submitting duplicate changes.

Context must be trimmed. History is not always better. Keep the goal, constraints, key decisions, and observations that have not expired. Replace verbose tool output with references and summaries. Otherwise, the window fills with old logs, and the constraints that actually matter get truncated out.

4. A Concrete Execution Pipeline

Using the example of “fixing a defect in a controlled workspace and submitting a description,” the pipeline can be broken into seven steps.

Step one: accept the goal and constraints—repository scope, directories that must not be modified, checks that must pass, and the delivery format. Step two: establish a read-only view—indexes, dependency manifests, and relevant tests, with no write access. Step three: form a verifiable plan—which files to change, why, and how to verify; the plan itself produces no side effects. Step four: request write permission per file or per changeset, limited to the paths covered by the plan. Step five: execute the modifications and run the agreed checks; on failure, revise within the step budget; if the budget is exceeded, stop and hand over the evidence. Step six: generate a diff, risk assessment, and rollback description, waiting for manual merge if necessary. Step seven: archive the session, tool traces, and final artifacts, then close temporary credentials.

In this pipeline, the model proposes and revises steps, the runtime enforces budget, permissions, and stop conditions, and business systems perform the actual reads and writes with their own auditing. With these three responsibilities separated, replacing the model or adding new tools does not force every business to reimplement orchestration.

5. Reliability, Cost, and Security

Stop conditions must include success criteria, step count, duration, tool invocation count, and cost ceilings. A loop without upper bounds will keep consuming quota when tools behave erratically. Retries should be limited to network timeouts, rate limits, and clearly transient errors. Parameter errors, permission denials, and validation failures should not be blindly retried.

Side-effecting tools must be idempotent. Use business idempotency keys for create, payment, notification, and publish actions so that resumed execution does not take effect twice. Read-only tools can be cached more aggressively, but the cache key must include tenant, permissions, and data version.

Evaluation should not only check whether the final text is fluent. At minimum, record: whether the task completed within budget, whether the correct tools were invoked, whether any permission boundaries were crossed, how many times a human had to intervene, how many rollbacks occurred, and the latency and cost distribution for similar tasks. Sampling and reviewing high-risk action traces is more effective at catching prompt injection and goal drift than looking at success rates alone.

Prompt injection must be handled as untrusted data. Web pages, tickets, code comments, and tool return values can all contain instructions like “ignore previous constraints.” System constraints, tenant policies, and hook decisions must take priority over external text. Tool parameters should be structurally validated before execution; do not concatenate raw text directly into commands.

6. Integration with Cloud-Native Capabilities

A managed runtime typically needs container platforms to host isolated execution environments, object storage for artifacts and checkpoints, message queues for asynchronous tasks, and logging and monitoring to observe step counts, error rates, and cost. Identity and access control should be scoped at the tenant, environment, and action levels. If a team already uses these general-purpose cloud services, the agent platform can consume the isolation, persistence, and observability infrastructure without embedding business orchestration into a single model request.

7. Rollout Sequence

Start with one low-risk, auto-verifiable read-only flow, and use a stateless single-run task to establish tool contracts and auditing. Then introduce stateful sessions, checkpoints, and human confirmation. Only after that should write access and external side effects be opened up. For each new category of tools, add permissions, idempotency, hooks, and evaluation first—rather than pursuing longer autonomous loops early on.

Message primitives remain the foundational capability. A managed agent adds goal tracking, loops, tool governance, and recoverable state on top. When tasks span multiple steps and systems and require accountability, the latter turns scattered prompt scripts into a runtime that can be embedded into a product.