A business case outlives an agent

An Execution should own a particular goal and its outcome. One may reconcile the original invoice. A later Execution may inspect an amended document. Another may prepare a consequential business action after approval. These units can each finish, fail or be replaced without erasing the business story that connects them.

The longer-lived object is a Case: an optional container for related work, evidence, artifacts, business entities, questions and decisions over time. It exists even when no model is currently running and no operation is waiting.

This does not imply that every customer request should become a Case. A quick report can simply produce an artifact. Cases earn their place when real-world continuity spans several activities, people or external dependencies.

A tempting design is to launch one agent when the discrepancy is discovered and keep it alive for weeks. But most of those weeks contain nothing to reason about. Work has stopped until a document, approval or deadline arrives.

Durability should attach to the business record and to specific waiting Executions, not to a permanently allocated conversational session. The Case can show open questions and references while individual work units are dormant or complete.

Separating these levels also makes accountability clearer. A Case has a business owner and lifecycle; an Execution has a goal, operations and evidence; an agent configuration describes how a worker might carry out one assignment.

Automation describes circumstances that can start new work: a daily overdue-invoice review, a newly submitted sales order, or an exception that matches a configured pattern. It is not itself an agent identity, a Case or an Execution.

A different situation is an Execution already waiting for a specific event. When the supplier's revised document arrives, the right behavior is to resume the targeted waiting work with fresh authority and evidence, not to launch an indistinguishable duplicate task.

The difference affects deduplication and concurrency. If the same event is delivered twice, should another investigation be created? If an earlier investigation is already active, should the new event attach to it? These decisions belong to the host's work policy.

An event source may report that an invoice was updated or that an approval was recorded. The temporal event layer can correlate such signals and indicate that a condition now holds. It should not thereby receive unlimited access to the business system.

The host must still identify the correct work item, validate the current principal and business context, and determine whether the requested operation is authorized and still meaningful. A persisted plan from last week is not permanent authority.

The event can also be negative information. If a supplier confirmation has not arrived by a deadline, the Case should show a missed commitment even if no agent spent compute during the intervening days.

For the person handling the dispute, a Case should present the linked invoice, prior investigation, corrected document, approval request and current status. Those may have originated from different Executions. The user should not need to reconstruct their relationship by scrolling through old model messages.

At the same time, history and state must remain distinct. The earlier conclusion should remain inspectable without masquerading as a current fact. A final verified correction does not erase the reason the dispute existed.

Attention can surface the one human decision required next, while the broader Case remains available for review. That is more useful than displaying an agent as 'running' throughout a week of inactivity.

Cases introduce extra state modeling, ownership and lifecycle decisions. They should not be introduced merely to rename a chat folder. A sound implementation needs stable relationships to business entities, durable work, evidence, deadlines and governance.

In Artemis, formal Cases and fully unified launch-versus-resume semantics are part of the vNext design, built on existing execution and event foundations. The public package for Event Intelligence is not itself proof that the complete Case architecture is live.

The architecture behind this distinction is described at https://github.com/sarooo17/artemis-architecture/blob/main/docs/12-CASES-AND-AUTOMATION.md.