Acpus
Acpus paper-cut wordmark

A durable agent workflow runtime

Describe the task,
Let your agent orchestrate the work.

your agent writes workflow.ts workflow carries any mix of ACP agents acpus keeps the run

The task — your words

Fact-check this article against the code and primary docs, challenge any weak findings, and wait for my approval before writing the cited report.

Your turn watch workflow.ts get written, checked, and run.

I

The file is real

Typed before it runs. Reviewed when it matters.

The authoring agent does not hand you a plan in prose — it writes real TypeScript, and Acpus checks it before a single node runs. acpus workflow check covers type diagnostics, authoring rules and value flow, then lowers the module into a frozen, serializable WorkflowIR — the same graph you just watched. The file is yours to read, diff, or review in a pull request; but most of the time, the agent gets it right because the type system won't let it ship nonsense.

check — before admission
$ acpus workflow check workflow.ts
✓ typescript          0 errors
✓ authoring rules     0 errors
✓ WorkflowIR          0 errors · 6 static nodes
viz — the graph, pre-run
$ acpus workflow viz workflow.ts
fact-check
input { article: string }
output …
agents: extractor (claude) · verifier (pi) · redteam (codex)

┌─ ✦ extract_claims · extractor
├─ ✣ verify_claims · fanout
│  └─ ✦ verify · verifier
├─ ✦ red_team · redteam
├─ ◌ publish_gate · signal
└─ $ write_report · task

II

Any ACP agent, one run

The graph is stable. The cast is a choice.

An Acpus workflow does not bind you to the agent that wrote it, nor to a single model vendor. Through the acpx / ACP boundary one run can cast claude to extract, pi to verify and codex to attack — and recasting is a configuration change, not a rewrite. Fork the run with a new mapping and compatible completed work is reused inside dependency boundaries, not re-done.

  • codex
  • claude
  • pi
  • trae
  • opencode
  • gemini
  • cursor
  • copilot
  • qwen
  • + any raw ACP command

recast a node — watch the fork

click a node's agent badge to recast it

III

Control is durable

The agents do the work. Acpus keeps the run on track.

Every run is held in workspace-local SQLite with frozen run files; the CLI tree and the web graph are two projections of the same durable state. Pause writes a durable gate. A signal is a durable input. A retry targets exactly one node. A fork opens a new run that reuses compatible completed facts instead of starting over.

acpus runs inspect

Follow the durable run state in the CLI.

acpus runs pause

Set a durable pause gate; active attempts wind down.

acpus runs resume

Clear the gate; scheduling resumes.

acpus runs retry

Retry one failed node, not the whole graph.

acpus runs signal

Deliver a waiting signal; the run continues.

acpus runs fork

Fork with a new cast; compatible facts carry over.

IV

Run once — or keep it

Disposable for the task. Durable when retained.

Not every workflow deserves permanence, and none needs a second format to earn it. The same workflow.ts serves a one-off afternoon and a team's recurring machinery — the difference is only what you do with the file afterwards.

rm workflow.ts

Disposable for the task.

One-off research or triage ends here. The run record stays in the workspace; the file goes.

git commit workflow.ts

Durable when retained.

An orchestration that solved a recurring problem becomes a reviewed, versioned asset.

.acpus/workflows/fact-check/

Ready to re-run.

Keep it in the catalog — or let it travel with a skill — and run it again with new input.

Acpus expands the boundaries of your agent’s intelligence.
Try use it in your everyday work.

Ask my agent to build a workflow ↗