Xevol procedure editor with purpose, required steps, input types, and revision publishing.
Configuring the two-step cafe-opening procedure.
Xevol run view showing revision 1, one of two required steps, cash input, and blocker controls.
After the first step, the run shows the next input, progress, and blocker controls.

From a procedure to an accountable run

The example has two required steps: disable the alarm and count opening cash.

  1. Define and publish

    Give the procedure a purpose, order its steps, and choose acknowledgement or typed input. Publish a revision rather than silently changing instructions already in use.

  2. Assign and carry out

    Start a run or assign it with a due date. Staff see the revision, required-step progress, current input, and an explicit way to record a blocker.

  3. Review the record

    The run shows its event history; the history view lists status, revision, assignee, and progress.

These screens show one implemented workflow inside a broader company workspace. They do not establish paid usage, time savings, or production reliability.

Operating problem

A checklist says what should happen, but rarely preserves which version someone followed, where the work stopped, or who completed it. Agent-assisted work adds another need: explicit boundaries around consequential actions.

What changed

Kuan designed the workspace and built its supporting systems: relationship records, research, operating procedures, and review controls. This example follows a cafe-opening procedure from configuration into staff execution and history.

System scope

  • Product and interface design
  • Relationship records and durable research
  • Versioned procedures and staff execution
  • Agent tooling and human review boundaries

Technical constraints

  • Preserve the revision attached to a run when the underlying procedure changes.
  • Keep workspace permissions, required steps, and unresolved blockers explicit.
  • Make the same operational record useful to people and agent-assisted tools.

Evidence

Implementation
Procedure editing, publishing, assignment, step completion, blocking, and execution-history views exist in the reviewed code.
Boundary
This case does not demonstrate autonomous outreach. The inspected outreach-delivery implementation supports disabled and shadow modes only.

Technical foundation

Interface
React and TypeScript with shared UI components, localized routes, and query-backed procedure views.
Operating model
Workspace-scoped procedures, revisions, assigned runs, step state, and event history.

Key decisions

Separate instructions from execution
A published revision and an individual run are different records. This preserves which instructions were followed as the procedure evolves.
Make unfinished work visible
Required steps, blockers, abandonment, and completion are distinct states. A blocked run does not become a successful result.
Use structured work, not just chat
Typed inputs and explicit actions give people a reviewable record. Agent tooling supplements that record rather than replacing it with a conversation.

Need a delivery partner for your software project?

Share the market, constraint, current state, and budget reality in writing. If it looks like a fit, you will get a human response with the next step.

Start a project
Next case study BorderlessKit A managed U.S. setup service for founders outside the United States.