The case is the unit of work

Open the average AI product and the first thing you see is a chat input. The interaction model is the prompt. Each prompt is a fresh turn; the model reads the recent thread, decides what to do, replies. State lives in the conversation. When the conversation ends, the state ends.

This is the right model for assistance — research, drafting, exploration. It is the wrong model for operations. An operations agent has to keep working when nobody is looking. It has to remember that an RFQ from Tuesday is still waiting on a supplier reply on Thursday. It has to know that a purchase order created yesterday is now overdue for confirmation. It has to surface the right thing to the right human at the right time, and then go back to sleep until something changes.

The unit of work is not a conversation. The unit of work is a case.

What we mean by "case"

A case in Korso is a durable record. It has a type (rfq, purchase_order, supplier_followup, quote_pending, …), a stage in that type's lifecycle, a customer or supplier it belongs to, a working state — the data the agent is accumulating as it makes progress — and a complete history log of everything that has happened to it. The history is append-only. Every action the agent takes, every external signal that arrives, every operator override is logged with the skill that fired, the rule that applied, and the rationale.

The set of all active cases is what we call the Attention Surface. It is the answer to the question "what is the agent currently working on?" There are no hidden conversations, no half-finished prompts. Everything the agent cares about is a row in the cases table.

// Shape of a case row (approximate).
{
  id: 'case_018f3a...',
  type: 'rfq',
  stage: 'waiting_for_supplier',
  customer_id: 'cust_acme',
  working_state: {
    rfq_email_id: 'msg_...',
    line_items: [...],
    supplier_rfqs_outstanding: ['sup_alpha', 'sup_beta'],
    deadline: '2026-03-15T17:00:00Z',
  },
  next_reassessment_at: '2026-03-01T08:00:00Z',
  created_at: '2026-02-28T14:21:00Z',
  updated_at: '2026-02-28T14:23:00Z',
}

Why this matters more than it sounds

Once the case is the unit of work, a lot of architecture decisions stop being decisions. Consider:

Triggering. What wakes the agent up? Email arrives, webhook fires, schedule expires, operator clicks "advance," another case completes. Each of these is a signal that maps to a case — either an existing one or a new one. The classifier's only job is "which case does this belong to?" Once that question is answered, the agent's behavior is fully determined by the case state and the operating model.

Concurrency. What if two emails about the same RFQ arrive ten seconds apart? They both join the same case. The case has one workflow running against it at a time, with Temporal handling the exclusion. The race is solved at the case level, not the workflow level.

Approval. When the agent needs human approval, it doesn't pause a chat thread. It transitions the case to awaiting_approval, surfaces it on the Attention Surface, and continues working on other cases. The operator approves at their leisure. The case resumes from its persisted state, not from a re-prompted context.

Memory. What does the agent "remember" about a customer? Whatever lives in their cases — past and present. There is no separate memory store, no vector database of past chats, no fragile "remember to ask Acme about their NDA" jotted in a prompt. The structured history is the memory, and it's queryable.

Auditability. Every case is a complete, replayable record. When an operator asks "why did the agent send this quote?" the answer is in the case history with the rule, the inputs, and the skill that fired. No log diving, no token forensics.

What you give up

This model has costs. The most obvious one: it is harder to ship. A chat-first product can launch with a single endpoint and a prompt; a case-first product needs a state model, a workflow engine, a triage classifier, a reassessment scheduler, an Attention Surface UI, and an audit log before anything works at all.

It is also more opinionated. We have to decide, upfront, what counts as a case in the manufacturing operations domain. That decision is encoded in the case types, the lifecycle stages, and the operating model markdown. Get the case taxonomy wrong and the rest of the product fights you. Get it right and adding a new agent behavior is often a five-line change to the operating model — no new code.

We accepted both costs because the alternative — a chat-first ops agent — fails at exactly the place ops work happens: in the long tail of cases that take days to resolve, span multiple parties, and need to keep moving when no one is watching.

How this changes the UI

The visible surface of Korso looks less like ChatGPT and more like an inbox crossed with a CRM. The center of the screen is the Attention Surface — cases sorted by what needs attention next. Each case opens to its history log, the agent's current plan, and the actions available to the operator. There is a chat input, but it is one signal among many — operators talk to the agent the same way the agent talks to the rest of the world, by triggering signals against cases.

When operators describe what Korso feels like, the recurring word is "calm." There is no firehose to read. There is a prioritized list of work, and a clear story for every item on it. That feeling — operators trusting that nothing is silently slipping — is a direct consequence of making the case the unit of work.

Where this is heading

The bet underneath this architecture is that 2026–2028 is the era where operations agents move from prototype to production, and the products that win that transition are the ones that treat agent work the way operations teams have always treated their work: as a queue of structured, durable, accountable cases. The chat sidebar is the demo. The case ledger is the product.

We are about a year into building Korso this way, and every operational behavior we have shipped — RFQ handling, supplier follow-ups, PO confirmation chasing, quote expiry sweeps — has landed cleanly on the case primitive. None of them required a new architectural decision. That's the test we're using: if the next behavior fits without strain, the unit of work is right.