From chatbot to dependable worker

The runtime around the model

A useful answer in a chat is a good start. A recurring business task also needs a way to begin, find the right information, act within a defined scope, and leave evidence of what happened. Those responsibilities belong to the system around the model. In this guide we call that system a harness. It is a working engineering term, not a formal certification or a guarantee of reliability.

Think about a weekly status update. A person knows which project notes count, which changes belong to this week, and who can approve the message. A reusable system needs those choices written down. Otherwise a polished paragraph can conceal missing evidence, stale context, or an action nobody intended to authorize.

Seven moments in a run

Use this sequence as a map of responsibilities. A real implementation may combine steps or repeat part of the loop. What matters is that you can identify who owns each transition and what evidence it receives. A model proposing a tool call is different from that tool successfully executing it.

• Trigger: a request, event, or schedule starts the work.
• Assemble: load the task, approved context, relevant instructions, and current state.
• Decide: select the next bounded step or produce a candidate answer.
• Check permission: establish whether that action is within the permitted scope or needs review.
• Execute: call the tool and record its actual result.
• Observe: use the result as evidence for the next decision; stop or recover when needed.
• Finish: verify the output, save the relevant record, and deliver it through the agreed path.

Workflows and agents solve different problems

Anthropic's architectural distinction is useful here: workflows follow predefined code paths, while agents let the model direct more of the process and tool use. Begin with the simpler pattern when the sequence is already known; introduce flexibility where the task actually needs it.

For the status draft, collecting three named sources and saving one document can follow fixed rules. Deciding which blocker needs explanation may benefit from model judgment. Sending the update is a separate business decision. You can combine all three approaches in one system without making the whole process open-ended.

• Anthropic: Building effective agents

Walk through a weekly-status example

This example is illustrative. At the agreed Friday cutoff, the collector reads this week's ticket updates, project notes, and unresolved blockers. It keeps source identifiers and timestamps with the extracted facts. The drafting step receives only that evidence and a short format: progress, blockers, next actions.

If a ticket is marked complete but the project note says the work is still under review, the draft should expose the disagreement. It should not choose the more impressive version. If one source cannot be read, the run reports the missing source and follows the pre-agreed rule for producing an incomplete draft or stopping.

The project lead reviews the exact draft and its source links. Approval belongs to that version. If the draft changes afterward, the previous decision does not silently approve the new wording. This is a deliberate choice for this example; a different workflow should define its own authority and risk boundaries.

Ten clauses for an automation contract

A plan becomes easier to implement when it answers predictable edge cases. Use these clauses as a practical checklist. Not every workflow needs a large specification, but every consequential ambiguity needs an owner. Name unresolved decisions rather than hiding them inside a confident prompt.

Keep state useful and limited

State is the information a run needs to remember. It might include the last successful cutoff, an output revision, pending review, or a record that today's trigger has already been handled. It does not need to be an unlimited transcript of every interaction.

An idempotency key is a stable identifier used to recognize repeat attempts for the same operation. For a daily draft, an implementation might combine the workflow identity and the relevant calendar date. That is a design example: the actual key must match the operation's scope. A key alone does not prevent duplication unless the receiving system checks and enforces it.

Decide what a retry can repeat safely. Reading a source again and sending the same external message again have different consequences. Keep the record of attempted actions separate from the record of confirmed results, so recovery can resume from evidence rather than from assumptions.

Read a real architecture without copying the whole stack

Hermes is one implementation you can study alongside this map. Its architecture documentation describes the components around the conversation loop. Use it to ask where context, tools, sessions, and execution belong, rather than treating its particular file names as requirements for your own project.

Start with your smallest useful workflow. Compare a direct script, a fixed sequence of model calls, and an existing agent runtime against that need. The selection should follow the work you must operate and maintain. You have a useful first design when another person can explain the inputs, action limits, failure paths, and completion evidence from your plan.