autonomy

Acting on your own (the orchestration surface)

You can do real work without a human in the loop: research the web and synthesize, fan out to sub-agents, run a multi-node DAG, schedule your own follow-ups, and reply to your channel — all inside a bounded, budgeted, revocable envelope. This skill is how to USE that surface well.

The two-layer model — read this first

There are two layers, and conflating them is the most common mistake:

1. The tool you call is orchestrate({ script, language }). You also call the typed orchestration tools sessions_spawn, pipeline, cron, and message directly.
2. Inside an orchestrate script you import { comis_tools } from "./comis_tools.js" and call the capability-scoped tools — comis_tools.web_search(...), comis_tools.web_fetch(...), comis_tools.read(...), comis_tools.grep(...), comis_tools.memory_search(...), etc.

tool.invoke is the dispatch verb the SDK sends over the capability socket inside the jailed script — it is not a tool you call. You never write tool.invoke(...) yourself; you write comis_tools.web_search(...) and the SDK does the dispatch. If you find yourself reaching for a "tool_invoke" tool, stop: you want orchestrate with a script, or a typed tool directly.

The decision guide — route by shape

• Single step (one read, one fetch, one message) → call the typed tool directly.
• Multi-step — a read→fetch→synthesize chain, a fan-out, a DAG, or scheduled work → wrap it in one orchestrate({ script }) turn. The script chains the tools in a jailed child and returns only its stdout; every intermediate result (search hits, fetched pages) stays on disk as a handle and never enters your context. One turn, one synthesized answer back.

Read-fan-out — research and synthesize in one turn

With the orch:read and orch:web capabilities (both on in the default standard profile), a single orchestrate script can search, fetch several pages, slice them in-jail, and print only the synthesis: