The conversation is not the execution

Consider a finance request: investigate a discrepancy, reconcile three data sources, ask an approver, wait for a corrected invoice, and then report the verified outcome. A chat transcript can narrate the entire story. It cannot by itself guarantee that the pending approval, revised record and final verification remain attached to a stable unit of work.

The unit needs its own identity. It must be possible to inspect it after the conversation has moved elsewhere, distinguish a running step from an external wait, recover from interruption and understand whether the goal was satisfied. That unit is an Execution.

This is an architectural boundary, not a proposal to hide chat. Conversation remains valuable for giving direction, resolving references and explaining results. It should not double as a transaction log, scheduler, source of truth and user interface all at once.

A useful Execution owns a goal, a target or subject, relevant context references, an evolving set of operations and an eventual outcome. It also owns relationships to independently delegated work, outstanding questions, external waits and evidence. These are operational objects that should not disappear because a summary of an old conversation was compacted.

This makes a crucial difference when a person asks, 'Is the supplier check done?' The system should consult the relevant Execution's state rather than infer completion from the last assistant message. A tool call can succeed while the requested business result remains pending.

Similarly, two orders can have similar conversation wording without being the same task. Stable references and owner scopes prevent accidental merging of unrelated work simply because a semantic search found similar language.

The most obvious agent architecture is an alternating loop: call the model, receive tool calls, execute them, call the model again. That loop is useful for some open-ended reasoning. It is not the right owner for every type of continuation.

A task might next need a deterministic computation, a bounded interpretation, a governed action, verification, delegation, a human decision, a long wait, completion or failure. These are different operations with different costs and failure semantics. Calling the model merely to discover that an approval has not arrived adds no value.

In the Artemis vNext design, the durable runtime should own this grammar of work. Model reasoning participates where useful; it does not decide by assertion that policy is bypassed or that a real-world postcondition has been met.

Suppose a finance approval arrives four days after the investigation started. A new run with the original prompt might duplicate actions, miss new facts or rely on old authority. A correct resumption must identify the exact waiting work and what it was waiting for, then check what has changed.

That includes revalidating relevant business records and permissions. A durable intention to submit an invoice is not a permanent authorization to do so. The user may have lost access, the invoice may have been revised, or another actor may have completed the step.

Independent child Executions need equally precise behavior. Waking one supplier branch does not mean that a parent whose finance approval is pending should also complete. Continuation depends on declared conditions, not enthusiasm about an incoming event.

If work is durable, the interface can be more flexible. A single workspace may show a report being generated, an invoice awaiting approval and a supplier investigation waiting for a document. A user can move among views without manufacturing three unrelated chat silos.

Work Surfaces display and manipulate business objects and artifacts; an attention system highlights blockers, decisions and meaningful outcomes. The global conversation helps the user steer the whole environment. None of these objects needs to become identical to the Execution.

The trade-off is more engineering: identity, scheduling, idempotency, policy, recovery and user-facing state become explicit responsibilities. But that complexity already exists in real business processes. Keeping it out of the architecture merely pushes it into ad hoc prompts.

A meaningful test is to start work, change focus, stop an active model session, receive an external approval, and then inspect whether the correct Execution resumes with appropriate context and authority. The user should be able to explain what is done, pending, blocked and verified.

That test is stronger than asking whether the agent can complete a multi-step request in one uninterrupted demo. It probes whether the product treats work as a durable entity rather than a long-lived conversation trick.

These are Artemis vNext principles, not a statement that the entire Execution-centered lifecycle is already shipped. The corresponding public design note is https://github.com/sarooo17/artemis-architecture/blob/main/docs/04-CONTINUATION.md.