Omnislash — the governed runtime for autonomous operations

  • Durable Kill the box mid-run. The same turn resumes and settles exactly once.
  • Governed Nine parallel runs hit one wall — you get one approval card, not nine.
  • Self-improving It rewrites its own playbook, and only ever as a graded pull request.
  • Yours Your repo, your keys, your box. 130+ tools, any vendor’s agents.
one run, end to end

Write how your company works as a brain in markdown.

Agents run it as real operations — governed, durable, improving by pull request.

The brain is a git repo you own. The engine — durable runtime, one human approval queue, 130+ tools over MCP, graded self-improvement — is inherited, not built. Self-hosted: your repo, your keys.

scenarios/revenue-recovery.md run complete

# revenue-recovery

every monday · 07:00

run #4127 · triggered mon 07:00:04

- pull the week’s failed payments

stripe.payments.list — 47 found 1 of 130+ tools · MCP

- retry each one, safely

pod killed mid-retry 07:03:41

resumed the same turn — 41 recovered, settled exactly once durable

- anything over $500 — ask finance first

paused — one approval card → @finance

approved 9 min governed

- post the recovery summary

posted to #revenue $18,204 recovered

- improve this playbook from what happened

PR #214 edits this file — graded 0.94, merged self-improving

You wrote six lines. The engine did the rest — and every mechanism it used is proven below, with the file behind it.

The run those six lines became — tasks, cost, and the live transcript, on the desk and in your pocket.

Hosted platforms

Run agents on their infra, their model, their console.

Omnislash

Your repo, your policy gate, any vendor’s agents.

The agent-OS wave

Runs anything, governed by nothing.

How your company works — pulled out of Slack, tickets and people’s heads, and safe for an agent to run.

Refunds, pricing exceptions, incident response — the knowledge that today lives in fragments and in people. Omnislash keeps it as a living, versioned map the engine can read and act on, kept current without anyone curating it. Memory is searched and injected before every turn, so an agent acts on what the company knows, not on what fit in one prompt.

  • Memory does active recall — auto-searched and injected before every agent turn. No memory_search call to remember; last week’s lesson is context for tomorrow’s first turn.
  • It stays current on its own: LLM dedup on write, priority compaction, a 30-day temporal-decay half-life, incremental sync, and grounded REM backfill that promotes validated observations.
  • The brain is a git repo, not a wiki — constitution, memory, skills and scenarios, diffable and hot-reloaded. Every memory write is committed: auditable, yours.
acme/brain live · hot-reload
  • constitution/ rules · eval methods · hooks gates every run
  • memory/ what the company knows +3 commits · today
  • skills/ SKILL.md catalog · from any git URL hot-reloaded · 2m
  • scenarios/ playbooks the engine plans and runs next · mon 07:00
before every turn search inject act no memory_search call — it just remembers
  • LLM dedup on write
  • 30-day decay ½-life
  • grounded REM backfill
  • vector + full-text · 8 languages
A git repo, not a wiki — every memory write is a commit: diffable, auditable, yours.

Those four folders are not a metaphor for a UI — they are the UI. Here is the same brain as the engine renders it: what it remembers, the jobs it knows how to run, the skills it discovered, and the schedule it keeps.

  • Vector memory — what the brain remembers, scored and decaying over time.
  • The scenario catalogue: every job the brain knows how to run.
  • A scenario open in its editor — prompt, model, skills, schema, all editable in place.
  • Skills discovered from the brain repo and offered to agents.
  • Heartbeats — recurring self-checks on a schedule, with their last outcome.
  • Event-driven hooks: what fires on which engine event.
  • Custom agent roles — the personas a brain author defines and their capabilities.

Same seven screens, same build, in a pocket — the brain is readable from a phone because a company’s knowledge is consulted where the question is asked, not where the desk is.

Most “make your knowledge executable” tools stop at the skills file. The harder question is the one only production asks: how does an agent run it safely against real systems? Omnislash answers it — capability grants with TTL, a human queue on every risky action, a per-run sandbox, and a definition-of-done check on the output. The knowledge is the easy half; the safe execution underneath is the half that’s already built. See the mechanisms →

You write a brain. You inherit a framework.

Same relationship a Next.js app has to its platform: the brain — markdown prompts, capability declarations, planner methods, one omnislash.config.ts — is yours, diffable and self-hosted. Everything else you inherit, not build: every mechanism this page goes on to prove, plus the stack that’s normally a 12-month project. No queue wiring, no Postgres schema, no Restate handler, no retry logic, no dashboard.

you wrote

  • daily-documentation-sync.scenario.md schedule: every day 10am · 6 steps
  • omnislash.config.ts one defineProject() stub

2 files · diffable · yours

you inherited — did not write

Data & execution

  • PostgreSQL + Drizzle
  • Redis — queues · streams · pub/sub
  • BullMQ job orchestration
  • Restate durable execution
  • distributed rate limiting

Observability

  • Grafana — dashboards + alerts → Telegram
  • Prometheus metrics
  • Loki logs
  • Sentry errors
  • Bull Board queue view

Operations

  • one Docker image → 6 services
  • omnislash dev / start / prod
  • doctor · upgrade · versioned db migrations
  • auto-TLS via Caddy
  • record & replay any run · 0 tokens
plus the engine itself
  • planner
  • durable agents
  • HITL governance
  • per-run sandbox
  • 130+ governed tools
  • memory + active recall
  • self-improvement loop

the stack that’s normally a 12-month project — ships with the engine

scale — one tick, one component hover a tick to name it

2 authored 22 inherited — the 12-month project 1 : 11

None of that is a roadmap. Here is the inherited half as it actually renders — the health page, the doctor, the shell, the model fabric, the integrations, the tool registry, the capability set, the environment and the settings, on the build this page was written against.

  • System health: queues, workers, Redis, Postgres and provider status.
  • Doctor — every configuration check the engine runs on itself, graded.
  • A real shell into the running container, in the browser.
  • The model roster: roles, fallback chains, routers and per-model pricing.
  • Connected third-party accounts and MCP servers.
  • The tool registry: every tool an agent can call, with its risk and HITL policy.
  • Tool call statistics — what actually gets used, how often, and how it fails.
  • The capability catalogue with one capability expanded to its tools and risk.
  • Effective environment configuration, with secrets masked.
  • Operator settings for the control plane itself.

The brain is the part that’s yours. The engine is the part you’d hate to build — and it’s already built, by one person, running in production.

receipt · brain-example/constitution/Scenarios/Engineering/daily-documentation-sync.scenario.md · docs/replay.md (record & replay any run at zero token cost)

Grab the wheel of a running agent, or let a boss agent clear your queue. Either way — every action, every approval, every dollar is on a record you own.

Autonomy is only safe if you can intervene, so intervention is a first-class mechanism on both ends. Take the wheel: step into any live agent’s conversation while it works, steer it with messages, and hand control back — no cancelling, no restart, the session keeps its context. Or let go: a Boss Agent resolves the queue by policy — auto-approving low-risk grants, routing questions to specialists, escalating only what truly needs you. And wherever you sit on the dial, everything lands in an operational record you own — every action attributed to its agent, run and cost, every trace replayable, on your infrastructure, next to your data.

the control dial choose per run · move it mid-run · set to manual assisted auto

Step into a live run, steer it by chat, hand control back. No cancel-and-restart — the session keeps its context.

the 3am · at manual
03:12 run ▸ needs calendar:write
risk: low
↳ card raised · run suspends at zero compute
↳ your phone: approve · approve in part · deny
03:14 run ▸ needs an infra endpoint (Grafana)
risk: high
↳ same card, same queue, same table
or take the wheel: steer the live run by chat, hand it back
nothing moves until you say so

You approve the risky steps. Everything else just runs.

the same 3am · at assisted
03:12 run ▸ needs calendar:write
risk: low
↳ matches a standing grant · scoped · TTL
↳ auto-cleared · logged · the run never stops
03:14 run ▸ needs an infra endpoint (Grafana)
risk: high
↳ no standing grant → one card, however many callers
↳ run suspends at zero compute until you answer
you get the decisions, not the noise

A Boss Agent works the queue by policy — approves low-risk, routes questions, escalates only what truly needs you.

the same 3am · at auto
03:12 run ▸ needs calendar:write
risk: low
↳ Boss Agent triages the queue by policy → approved
03:14 run ▸ needs an infra endpoint (Grafana)
risk: high
↳ policy says this one is yours → escalated, held
↳ and it is the only thing waiting for you at 09:00
every decision keeps its actor and its reason on the record
the dial changes who answers — never what the agent asked for. agents supervise their own child agents, all the way down.

Most frameworks give you one lever: cancel. Step away and the run is unsupervised; step in and you lose everything it did. Here both moves are non-destructive — you can drop from full manual to full autonomous and back without ever throwing away work in flight.

The wheel and the boss are the same primitive seen from two ends: one durable conversation you can always reach into, and a queue an agent can clear when you’d rather it didn’t reach you at all.

  • The Agents Matrix — every live agent in one split-grid war room, each tile a running session you can open and steer.
  • Pinning agents derives the war-room grid: several live transcripts side by side.
  • The control plane at a glance: spend, live runs, agent health, recent evaluations.
  • The agent roster as a dense list — status, model, source, cost per agent.
  • The same roster as cards — the browsing layout for a smaller fleet.
  • Spend over the last 30 days, sliced by whatever dimension you ask for.
  • The same cockpit re-pointed: 90 days of tokens by week, pivoted per agent.
  • The raw engine event log — the audit trail behind every screen above.

The record has an outside edge. When a run makes something a person should actually read — a report, an audit trail, a diff — the agent doesn’t paste it into a chat and hope. It publishes the file and hands back a URL: one link, revocable, expiring when you said, operator-only if you asked. The link outlives the run that made it.

One rule there looks paranoid until you see the attack it closes. A publication may change its bytes, never its file type — otherwise whoever holds a link to a rendered report could turn that same trusted URL into an arbitrary page on your own domain.

the deliverable · a file becomes a link
agent writes
artifacts/…/weekly-report.html
publish_artifact
→ https://artifacts.<you>/p/<id> — rendered, openable
a snapshot
the bytes are copied; the working file may change or die
replaces
new bytes, same URL — a living document keeps one link
alias
/a/weekly-report — readable, and guessable BY DESIGN
expiresInHours
stops serving by itself — derived, never swept
private
same link, operator login — checked in the route, not the proxy
revoke
the URL dies, the row lives on for the audit trail
format frozen for the URL’s lifetime — the bytes may change, the kind may not

every artifact a run produced, content-addressed and publishable

It’s not a dashboard you check after the fact — it’s the operational surface the agents run inside, mobile-ready, because the approval that unblocks a 3am run shouldn’t wait for you to reach a laptop. Agents do the work. You own the audit trail, the policy, the data, and the repo.

Every AI platform hits the same wall: one critical workflow outgrows “the agent figured it out,” and you leave. Here you don’t leave — you escalate that one workflow a tier up.

AI end-to-end handles 80–90% of operations. The rest eventually need more predictability than autonomy gives. Most platforms force an all-or-nothing choice; Omnislash gives you a dial per workflow — keep the easy 90% AI-managed, and pull the mission-critical ones down to a locked blueprint or hand-written code, on the same runtime, same agents, same governance.

AI end-to-end

for business operators

Describe it in plain language. The Cascade planner builds the plan, durable agents run it, eval grades it, the loop improves it.

Agents decide the flow.

AI + blueprint lock

for power users, analysts

Let AI draft the plan, then freeze it: export the blueprint, edit tasks and DoD, lock phases. Deterministic — no re-planning per run.

AI drafts, you freeze the structure.

Code-defined

for software engineers

Write a typed Restate pipeline in TypeScript. Every step, branch and error handler is code; agents are called as typed steps, not autonomous actors.

You own the flow; agents run steps.

describe & run lock the blueprint engineer it — per workflow, not per account

  • The scenario catalogue: every job the brain knows how to run.
  • A scenario open in its editor — prompt, model, skills, schema, all editable in place.
  • Authoring a workflow blueprint: phases, tasks and their contracts on a board.
  • Task breakdown expanded — description, definition of done, agent and spend per task.
  • Every run the engine has executed, grouped by status, with cost and duration.
  • One run in flight: phase strip, live tasks, and the rail to switch runs.
who offers which tier · july 2026
platform tier 1 tier 2 tier 3
n8n · Zapier · Make visual
LangGraph · CrewAI yespartial
Temporal · Restate yes
Omnislash yesyesyes

Most platforms are built for exactly one of these tiers; Omnislash spans all three, with a path between them. A Tier-3 pipeline isn’t a separate product — it inherits the entire runtime: the same agents, eval, memory, tools, HITL and scheduler the AI tiers use, called as typed steps.

You never outgrow it — you escalate into it.

all three tiers land in the same run list, graded the same way

what one instance runs · illustrative mix 63 workflows · one deployment
  • 50 · tier 1 — AI end-to-end
  • 10 · tier 2 — AI + blueprint lock
  • 3 · tier 3 — code-defined

Two of these didn’t start in the column they’re standing in — they were escalated a tier, one workflow at a time, on the same instance. The other 61 never moved, and nothing had to be migrated for them.

The internet is built for humans clicking. Agents get a surface they can read, call — and be trusted with.

Machine-readable interfaces — catalogs, APIs, MCPs — are what let an agent work without a person driving. Omnislash ships that surface both ways: the engine’s 130+ tools are discoverable and callable by any agent over MCP, and the same declarative pattern makes your own product agent-ready — declare it in config, the engine provisions and governs it.

  • Discovery is programmatic — every tool carries a domain:capability declaration and a risk level an agent reads before it calls. No docs-scraping, no guessing.
  • Adding a tool is declarative — the brain declares auth, webhooks and tools in config; the engine provisions the endpoints, wires the authorization and exposes them. No per-integration boilerplate.
  • Every call is governed — a capability grant with a TTL, approvable in part: calendar:read yes, calendar:write no. Discoverable for the agent, gated by the same queue a human signs off through.
  • It runs the other way too — an agent can work a channel as a person, answering in your own DMs with no bot chrome. The same gate applies from the inside: every tool call it makes there is pinned to that one conversation.

The surface

what an agent finds when it looks

  • mcp server the whole surface · stdio local · HTTP prod
  • tool registry 130+ tools · domain:capability + risk level
  • integration kit auth · webhooks · tools → provisioned
  • 80+ built in Google · Notion · Figma · MTProto · n8n
  • oauth store encrypted · auto-refresh · stays signed in

Headless OAuth

the redirect becomes a consent card

  1. agent hits an OAuth MCP server — headless, no browser
  2. registers itself (DCR) · PKCE · resource indicators
  3. the redirect, inverted → a durable consent card: grant calendar:read to research-agent? TTL 30 days · risk: low · via Telegram
  4. a human taps approve — hours later, from a phone · or a browser agent drives the consent itself (human card as fallback)
  5. the paused run resumes with the fresh token

The card above is drawn. The real one is photographed below it. The full machinery — HMAC state, replay guards, one-shot PKCE, per-issuer DCR locks — is one tab away: Headless OAuth →

ways in

  • chat
  • schedule · “every weekday 9am”
  • webhook
  • event hooks
  • MCP call
  • file drop

ways out

  • progress cards
  • approvals
  • alerts
  • deliverables · published artifact links
  • replayable stream
  • your ops over MCP
you wired none of it — webhook server, cron, event bus, notifier ship with the engine

None of that surface is a diagram of an intention. Every tool an agent can call is a row with a declared capability, a risk level and a HITL policy — and every call it makes lands in the statistics beside it.

  • The tool registry: every tool an agent can call, with its risk and HITL policy.
  • The capability catalogue with one capability expanded to its tools and risk.
  • Tool call statistics — what actually gets used, how often, and how it fails.
  • Connected third-party accounts and MCP servers.
  • Inbound and outbound webhooks with their delivery history.

The operation improves between runs — and you can read the diff of everything it learned.

Most automation is an open loop: it runs, and a human checks later. Here the loop closes on the record — every action lands in one searchable activity stream and a real control plane, and a failed check branches a recovery agent that patches the plan and resumes. And when the engine edits its own playbook, the edit arrives as a pull request. The lesson is a file in your repo; the improvement is a diff. Here is one.

observeplanexecuteverifyimproveSELF-CORRECTINGthe loop
Fig. 01 · verify fails → plan patched → run settles

the diff — PR #214, off the run at the top of this page

constitution/Scenarios/Finance/revenue-recovery.scenario.md

  1. - pull the week’s failed payments
  2. - retry each one, safely
  3. - retry each one, safely — but hold a card_declined until the next business day; a same-day retry re-declines and burns the customer’s bank retry limit
  4. - anything over $500 — ask finance first
  • graded run #4127 scored 0.61 — under this scenario’s bar. Analysis fires only there.
  • re-run on the input it studied, plus recent inputs from this scenario’s history it never saw.
  • verdict 2/3 challengers passed (61% → [94%, 88%]). A pass counts only if it also beats the baseline; a tie counts as regressed.
  • filed the lesson is written on a loss too: “this mutation made it worse — don’t retry it here.”

The verdict is advisory. Merging is a button only you press — and so is the revert.

the fence — self-improvement can’t game its score

  1. a self-edit arrives as a pull request — never a silent write
  2. touches its own grader? auto-closed before it ever runs
  3. survivors run A/B against the baseline on held-out inputs
  4. win → adopted · regression → a revert PR, also yours to merge

Every proposal that survives the fence queues up in one backlog . The rubric fence and its cited receipts are one tab away — Self-improvement →

The live event stream — every domain event the engine emits, as it happens.
The same stream rendered as a WebGL flow scene.

The ring is a diagram of something already running. Here is one lap of it on the record: the run list, a run in flight, its tasks, what it cost, the grade it earned, the change it proposed about itself, and the backlog that change lands in.

  • Every run the engine has executed, grouped by status, with cost and duration.
  • One run in flight: phase strip, live tasks, and the rail to switch runs.
  • Task breakdown expanded — description, definition of done, agent and spend per task.
  • Usage & Cost for a single run: tokens, cache hits and money per task.
  • The evaluation verdict — the run graded against its own definition of done.
  • What the engine proposes to change about itself after grading the run.
  • The self-improvement backlog: proposals raised by runs, with their status.

Every framework says “reliable” and “safe.” Pick a failure you’ve lived — here’s the line of code that kills it.

Eleven mechanisms a skeptical staff engineer would want to see before trusting an agent with production. Each names the failure in your vocabulary, the exact primitive that fixes it, and a test you could re-run. Use the index to jump.

One of them no lab will ship: the labs each orchestrate their own agents. Omnislash runs all of them — claude, codex, opencode, API models — under one policy gate, with cross-harness fallover mid-task. Model fabric → What each one costs a turn →

Durability · the failure every framework ships

Kill the worker mid-run. It resumes the same turn — not the task from scratch.

A HITL wait in most frameworks is a blocking thread or a from-scratch rehydrate, so a crash mid-wait loses the turn. Here the entire session is one Restate virtual-object invocation, keyed by agentId: it owns the prepare, the subprocess turns and a multi-day human pause, suspended at zero compute while still holding its exclusive per-key lock. It journals the resume handle via ctx.set before ringing the lifecycle bell, and a finally clears it on every exit — so single-writer ordering, callback identity and exactly-once settlement fall out of the live invocation for free, not rebuilt across a rehydrate.

durable run
run ▶ step 3 / 7
✕ crash
server killed · redeploy · network lost
↻ reconcile orphan
(sys_invocation = liveness oracle)
run ▶ resume @ step 3 / 7 ← not step 1
mailbox · HITL pause · scheduled turn · stop — all survive

receipt · agent-vo.ts:639-666 (ctx.set before the bell) · real-Restate test agent-vo.integration.ts:508-595 asserts exactly-once settlement across a kill.

  • One run in flight: phase strip, live tasks, and the rail to switch runs.
  • Task breakdown expanded — description, definition of done, agent and spend per task.

Durability · the bug only production shows you

You dispatch an agent and hit stop a millisecond later. The naïve design no-ops and the agent runs on.

The agent row still reads idle — current_invocation_id is projected only after the virtual object grabs its per-key lock. So control here never trusts the read model: stop, liveness and the HITL barrier all query Restate’s sys_invocation over SQL, which is ground truth. Two details prove this was learned in production, not whiteboarded: Restate serves binary Arrow IPC unless you ask for JSON, and a finished invocation lingers ~24h as completed — so the orphan reconciler filters status != 'completed' and re-verifies each run individually. A stale batch read can never mass-false-resume.

ground truth vs the projection
stop fired 1ms after dispatch
agent row.current_invocation_id
= NULL ← projection lags
sys_invocation status
= running ← truth
→ gate on sys_invocation. the stop lands.
orphan sweep: classify in ONE query (status != completed)
re-verify EACH run before resume · recover via stealFrom CAS

receipt · restate-client.ts:481-495,:274-311 · AgentController.ts:489-522.

  • The raw engine event log — the audit trail behind every screen above.
  • The live event stream — every domain event the engine emits, as it happens.

Governance · the rogue-agent fear, as a database problem

Nine parallel runs need the same permission. You get one approval card, not nine — and you’re never re-asked.

A framework without a shared HITL ledger — which is nearly all of them — raises N prompts for N callers needing sign-off, by construction. Omnislash collapses them with one Postgres upsertON CONFLICT (dedup_key) WHERE status='pending', first-writer detected via xmax=0 — keyed on [subject, scenario, sorted-caps] with the producer omitted, so a pipeline, an agent and a workflow converge on one card. One approval fans back out to an awakeable, a paused virtual object and a workflow FSM, each wake idempotent. The decision is CAS-committed to Postgres before the grant is issued; die in that gap and a 15s reconcile sweep replays it — the human is never re-asked.

coalesce & fan-out
9 pipelines + 1 agent + 1 workflow ─▶ hit: calendar:write
ON CONFLICT (dedup_key) WHERE status='pending' → 1 row, 11 subs
operator approves ··· once
fan-out (idempotent): awakeable · paused VO · workflow FSM
decision committed BEFORE grant → die in gap → 15s sweep replays
forged actionId on the wire → rejected vs the declared set
one hitl_interactions table · 4 fragmented pipelines deleted

receipt · grant-dedup.integration.ts:34-158 · validateApprovalActions.ts:111-124 (forged-button rejection).

  • The human-in-the-loop queue: questions, approvals and grant requests in one inbox.
  • A grant request opened — which capabilities an agent is asking for, and why.
  • Partial approval: grant some capabilities, deny the rest, cap the TTL.
  • Live grants — what each agent may currently do, until when, and how often.

Isolation · “cool demo” → “I’d run it on my prod”

The vendor’s CLI owns its own subprocess and never hands you argv. So we jail it through the one seam it exposes.

The Claude and Codex SDKs spawn their CLI internally and expose exactly one knob — an executable-path override — so the engine points it at a bwrap shim that execs the real jail: --ro-bind / / --proc /proc --unshare-pid --unshare-ipc --die-with-parent. It binds the per-run git checkout over /app/brain so every absolute path still resolves, and binds the artifacts root RW at its own sibling absolute path — so the agent’s declared output reaches the validator while a write to /app/brain stays trapped in a throwaway clone. The boot gate probes the exact namespace combo and refuses to start if it can’t actually jail.

the jail topology
bwrap shim (via the SDK’s one executable-path override)
--ro-bind / / --tmpfs /tmp --proc /proc
--unshare-pid --unshare-ipc --die-with-parent
bind per-run checkout → /app/brain (writes trapped, disposable)
bind artifacts root → RW (agent write = validator read, one inode)
per-run repo = git clone --shared --local · alternates → 0 copy · gc off
boot gate probes the EXACT combo → can’t jail? refuses to start.

receipt · bwrap-claude.sh:41-58 (verbatim argv) · artifactsTopology.integration.ts:115-161 (real-bwrap containment test).

  • A real shell into the running container, in the browser.
  • System health: queues, workers, Redis, Postgres and provider status.

Model fabric · the outage every subscription team has lived

Claude Code prints “resets 3:10pm (Europe/Amsterdam)”. We parse that into an epoch and pin the provider across the whole fleet.

resilience4j and opossum are in-process and threshold-only — every worker re-discovers the same dead upstream and burns its own retry budget. Omnislash turns the provider’s own wall-clock-with-timezone recovery string into an absolute instant (regex + Intl.DateTimeFormat) and an atomic Redis-Lua breaker pins the harness open until exactly that moment — the first worker to hit the wall makes every other process fast-skip it. The runtime itself is one string in one TEXT column. And when a chain falls over mid-task, the partial tool-use transcript is rebuilt from your own Postgres into vendor-neutral markdown that tells the successor: read this, do not redo committed work.

one ModelRef column
claude
CLI harness · your Max subscription
claude:openrouter:x-ai/grok-4.1
same harness · Grok via env override
openai:gpt-5.2
in-process AI-SDK call
claude,codex
cross-harness fallover chain
→ billing auto-flips subscription ⇄ metered
“resets 3:10pm (Europe/Amsterdam)” → epoch → Redis-Lua pin OPEN

receipt · redisCircuitBreaker.integration.ts:210-214 · handoff.ts:92-102.

The model roster: roles, fallback chains, routers and per-model pricing.

Model fabric · the bill nothing else in your stack itemises

Someone adds the sixtieth skill. Every agent in the fleet pays for it on every turn from then on, and no meter you own can say where the tokens went.

A turn opens with a prefix — the tool array, the system prompt, the memory envelope — that is paid on every single turn and never shrinks. A context-window meter shows one total for the last turn and cannot attribute a byte of it. Omnislash itemises that prefix per role by assembling the real prompt rather than a description of one, then names the lever rather than the number: this role’s skills catalog is a sixth of its prefix, give it a focus list. Two figures are never conflated — what is actually on the wire on turn one, and what is priced but deferred behind tool search. And the difference between harnesses is the part only a multi-vendor runtime can see at all: of the three the engine drives, exactly one hides tool schemas behind a search tool, so the same brain config that is a rounding error on one is tens of thousands of tokens a turn on another. Anything the report knows exists but could not price is counted unmeasured, never as zero — the total is an admitted lower bound, not a number that quietly omits the thing you opened it to check.

the prefix, per delivery
the prefix — paid EVERY turn, never shrinks
tool definitions · system prompt · context envelope
itemised per role
same brain, three deliveries, three bills
claude
turn-1 tools on the wire · the rest deferred behind search
codex · opencode
no deferral primitive → the WHOLE array announced
API model
its capability-filtered set, injected whole
where the report stops describing and complains
prefix ≥ 25% of the window
critical at 40% → trim the heaviest rows
≥ 30 tools priced, none deferred
pin a deferring harness · narrow the caps
skills catalog ≥ 15% of the prefix
give the role a focus list
≥ 5 tools announced, never called by ANY agent
disable by category
couldn’t price it → “unmeasured”, never 0. the total is a lower bound.
metrics down ≠ zero calls — an outage never reads as “unused”.

receipt · mcp-wire.ts:164 (the deferring-harness list is one entry long), :232 · thresholds.ts:14-42 (every judgement number, with the rationale beside it) · estimate.ts:28-31 (two chars-per-token buckets, ≈±15%, marked ≈ on every surface) · docs/context-budget.md.

  • The tool registry: every tool an agent can call, with its risk and HITL policy.
  • Tool call statistics — what actually gets used, how often, and how it fails.
  • The model roster: roles, fallback chains, routers and per-model pricing.

Planning · the silent corruption one-shot planners ship

A JSON schema can assert “an array of {taskId}”. It cannot assert “this set of task IDs equals the set produced three stages ago.”

So one-shot planners ship a plausible, broken plan the moment the LLM silently drops task-3 while mapping capabilities. Omnislash plans in up to 11 independently schema-constrained hops, and every enrichment merge runs assertTaskCoverage — diffing the stage’s task IDs against the live set and throwing with the exact missing ID, one targeted re-prompt, then escalate. Each stage snapshots to Redis before the LLM call, so killing the worker at stage 7 resumes at stage 8 with zero re-spent tokens. The final-review stage critiques the real assembled blueprint, but its output schema has no add-task or delete-task field — the worst self-review failure mode is impossible by construction.

the planner as a state machine
11-stage cascade · durable to the stage · resumable mid-pipeline
stage 1 → researchNeeded? → the ONLY ['*'] privileged stage
greps the real repo → 1 task per discovered item
enrich: each merge → assertTaskCoverage → drop task-3? throw w/ ID
final review → schema-whitelisted to 5 fields → can’t add/delete a task
kill @ stage 7 → resume @ stage 8 · 0 re-spent tokens

receipt · stageSchemas.ts:311-340 (the 5-field review whitelist) · buildPipeline.ts:71 (coverage assertion).

  • Authoring a workflow blueprint: phases, tasks and their contracts on a board.
  • Task breakdown expanded — description, definition of done, agent and spend per task.

Isolation · live edit vs pull request, decided at the git layer

An agent that edits its own repo is a good demo. The question production asks is which files it may touch while it runs.

The brain stays live: on the default rung an agent writes straight into the running checkout and a sync daemon commits and pushes — the agent never pushes. What makes that safe is that the daemon commits exactly a declared push surface and nothing else, so a write outside it is not merely “not hot”, it is never persisted — the container is writable, the write succeeds, and it vanishes on the next recreate. That silent loss is now a boot-time failure. A path in the set must be a directory, because a sparse-checkout anchor never matches a blob and a file there would lose every write. Two classes are forbidden outright, for blast radius rather than boot order: docker/ — an agent that can commit a compose override can mount the docker socket into its own container — and .github, where an edit is arbitrary code on the runner. Everything else is cold, and a live agent that needs one delegates to a rung that commits and opens a PR.

the write surface
runIn ladder
live ⊂ clone (+own git) ⊂ sandbox (+bwrap)
live (default)
writes the running checkout · daemon commits + pushes
clone
own pushable clone, no jail → durable edit → PR
sandbox
that clone, inside the bwrap jail
the push surface
memory/ · constitution/ · skills/ · features/
write outside it
succeeds → gone on recreate → now fails at boot
must be a directory
a sparse anchor never matches a blob
forbidden outright
docker/ (socket → own container) · .github (CI = code)
cold files
config · tools/ · db/ → the clone rung → commit → PR

receipt · brain-paths.ts:114-145 (the forbidden set, split structural vs blast radius) · project.ts:721-773 (the directory assertion, and the second door through contentRoots) · docs/agent-isolation.md (the ladder, and what each declaration site actually does).

  • Every artifact agents produced, content-addressed and publishable by URL.
  • What the engine proposes to change about itself after grading the run.

Self-improvement · autonomous, because it’s fenced

Most self-editing loops trust the model not to edit its own grader. That’s a prompt instruction it ignores the moment editing the test is the cheapest way to pass.

Before any self-improvement PR is validated, the worker runs gh pr diff --name-only and closes it — marking the improvement failed — if any changed path falls under constitution/Evaluation/ or constitution/Improvement/. The optimizer physically cannot edit the eval methods or improver prompts it’s graded by. Surviving edits face a measured A/B: rerun the scenario as N challengers over historical inputs the improver never saw, adopt only on a strict majority scoring ≥ baseline (ties and dead runs count as regressed), and on regression auto-open a mechanical revert PR. A regressed edit also distills a “do NOT retry this mutation” lesson into vector memory.

the fence and the A/B
self-improvement PR
gh pr diff --name-only
touches constitution/Evaluation/** or Improvement/** ?
→ CLOSE PR · improvement = failed (can’t edit its rubric)
else → rerun N challengers on held-out inputs (unseen by improver)
adopt iff strict majority ≥ baseline (tie / dead → regressed)
regression → auto revert PR + “don’t retry” → vector memory

receipt · protectedPaths.ts:11-21 (the fence) · validationVerdict.ts:15-39 (strict-majority verdict). Designed against DGM Appendix H + METR reward-hacking reports.

  • The evaluation verdict — the run graded against its own definition of done.
  • What the engine proposes to change about itself after grading the run.
  • The self-improvement backlog: proposals raised by runs, with their status.

Depth · the protocol most frameworks skip

Vanilla MCP OAuth assumes one user at a localhost loopback redirect. Our agent is headless and the human is on a phone, hours later.

Most agent frameworks treat MCP servers as no-auth or static bearer tokens. Omnislash implements the MCP SDK’s OAuthClientProvider so the official auth() orchestrator runs the full RFC 9728 / 8414 / 7591 / 7636 / 8707 flow unchanged — except redirectToAuthorization() doesn’t redirect a browser, it mints a durable oauth_consent row a human approves later from Telegram. The protocol scars prove someone got bitten by the real spec: HMAC-signed stateless state, a SET-NX replay guard, a GETDEL one-shot PKCE, a per-issuer DCR lock, and an RFC 7009 revoke if the token-persist fails. That consent card is the same hitl_interactions row as every other human pause.

redirect → durable card
agent hits OAuth-protected MCP server (headless)
DCR (RFC 7591) → per-issuer Redis lock serializes registration
auth() → redirectToAuthorization() → mints oauth_consent HITL row
state = HMAC · timing-safe · SET-NX replay · GETDEL one-shot PKCE
human taps approve in Telegram (hours later) → run resumes w/ token
token persist fails → RFC 7009 revoke (never strand a live grant)
one table backs: question·grant·approval·input·consent·interception

receipt · mcp-oauth-provider.ts:148,:419-477,:303-371 · oauth-state.ts:119-189.

  • Connected third-party accounts and MCP servers.
  • A grant request opened — which capabilities an agent is asking for, and why.

Depth · the capability that needs a fence, not a disclaimer

An agent replying as you, in your own DMs, is one API call away. Not being able to read the rest of your account is the hard part.

Connect a bot to Telegram Business and the engine runs turns on messages from the private chats you chose, replying on your behalf with no bot chrome at all: no status cards, no keyboards, no typing indicator, no reactions — one plain message. A failed turn is silent for the other person: no error bubble, nothing appended to a half-streamed answer; you get one plain note in your own control DM, and approval cards reroute there too. The connection id is a credential, never identity — the platform rotates it whenever you edit the connection — so state is keyed on (chat, bot, owner) and survives a disconnect and a rotation. The agent reads the real history through MTProto, including messages from before the bot existed that the Bot API can never see, and that is exactly why the fence exists: under a business chat every MTProto call is pinned to that one conversation. An account-wide tool, another chat’s id, or an explicitly named account is refused permanently. A counterpart-facing agent must not become a window into your whole account.

acting as the owner
someone writes to your account
engagement gate → agent turn → one plain reply, sent as you
status cards · keyboards · typing · reactions — all suppressed
turn fails → they see nothing; you get one note in your control DM
approval card → your DM, never theirs
credential ≠ identity — the connection id rotates on every rights edit
state keyed (chat, bot, owner) → survives disconnect + rotation
blast radius — every MTProto call pinned to THIS chat
dialogs · global search · a named account → refused, permanently
your own agent, in your own DM, keeps full access

receipt · helpers.ts:239-262 (the scope refusals, verbatim) · telegram-error.ts:35 (classified permanent, not retryable) · businessFailureNotice.ts (you get the failure, they don’t) · docs/secretary-mode.md.

  • The capability catalogue with one capability expanded to its tools and risk.
  • Live grants — what each agent may currently do, until when, and how often.

The mechanisms above are the deep ones. Here’s the rest of what already ships — all of it, at once.

A headless browser for agents, prompt-injection defense, transcription failover, multilingual memory, a database browser, service discovery — the surface is enormous because it’s years of plumbing you’d otherwise build. Focus a category below; everything else steps back.

116

capabilities · shipped, not roadmap

  • Agents & models
  • Durable crash-proof agent runtime (Restate virtual objects)
  • CLI harnesses: Claude Code · Codex · OpenCode
  • API: 24 providers, ~200 models via Vercel AI SDK
  • Role-based fallback chains with trace handoff · per-step @effort
  • Distributed circuit breaker (Redis-Lua, fleet-wide)
  • Adaptive rate limiting · auto-fallback on timeout
  • OpenRouter through any CLI harness
  • Structured output (Zod / JSON Schema) from any agent
  • Streaming via Redis Streams · namespaced subscribers
  • Session save / restore · history compaction
  • Multi-repository operations · auto-clone on deploy
  • Per-chat agent & model override
  • Context-window policy — per-role marks: nudge the chat, then auto-compact (never kills a live turn)
  • RunIn execution ladder — live · clone · sandbox, chosen per invocation
  • Security & isolation
  • Prompt-injection defense: cryptographic boundary markers on external content
  • Invisible-Unicode stripping · HTML sanitization
  • SSRF protection: private-IP blocking, DNS validation, redirect tracking
  • Per-run sandbox: bubblewrap namespaces + git-clone --shared + OverlayFS
  • Boot gate refuses to start if it can’t actually jail
  • Agent DB access with PG schema isolation (search_path=public)
  • Path containment + repo boundary enforcement
  • Infrastructure-endpoint grants (Grafana / Bull Board gated)
  • Capability grants with TTL — never blanket access
  • Brain-owned tool policy — engine-tools.json overrides risk & HITL per tool
  • Published artifacts render in an opaque origin — sandboxed CSP, no scripts, no network
  • What agents can do
  • Playwright browser: navigate · click · read · screenshot, any CLI provider
  • Attachments end-to-end: photos · audio · documents flow to the agent
  • file_send — agents send files back to chat
  • PDF text extraction · image resize / convert / optimize
  • Multi-provider transcription failover (Groq → OpenAI → Deepgram)
  • Web content extraction via Mozilla Readability (no external API)
  • OpenAI image generation · text-to-speech (ElevenLabs)
  • Child-agent supervision — spawn and monitor sub-agents
  • publish_artifact — file → immutable content-addressed snapshot at an unguessable public URL
  • Artifact links: human aliases · self-expiring · replaceable (stable living-document URL)
  • Artifact revocation with provenance — who revoked, capability-scoped
  • Browser-operator role built in — hardened Playwright agent, spawnable with zero brain authoring
  • Humans & governance
  • One HITL gateway: question · grant request · approval, one table
  • First-responder-wins CAS — every channel broadcasts, one side effect
  • Partial grants — approve a subset of requested scopes
  • Free-form corrections — LLM re-parses intended capabilities
  • Boss Agent triage — resolve the queue by policy
  • Operator interception — take the wheel of a live run
  • Runtime escalation — agent requests a missing grant mid-run
  • MCP OAuth as a durable consent card (approve from Telegram, hours later)
  • Structured input collection — typed forms via HITL
  • Heartbeat-scoped grants — one approval covers every future tick of a recurring agent
  • Robot OAuth — a browser agent drives the consent screen (login · MFA · approve); human card as fallback
  • Conversational approvals — a plain chat reply supersedes the pending card
  • Planning & workflows
  • 11-stage Cascade planner — minimal context per stage
  • Interactive clarification — up to 4 questions, only when it changes the plan
  • Capability routing · context groups · artifact planning
  • Final self-review fenced from add/delete-task by schema
  • Per-stage Redis snapshots — resume mid-pipeline, zero re-spent tokens
  • Phase-based orchestration — parallel within, sequential between
  • Eval vs Definition of Done + grounding check
  • Self-healing — a failed run spawns a recovery agent that patches the plan
  • Cost & usage analytics — per model / scenario / agent
  • Completion-report enforcement with artifact file sizes
  • Memory
  • Hybrid vector + full-text search (configurable weights)
  • Active recall — auto-searched and injected before every turn
  • LLM dedup on write — only new information kept
  • Temporal decay — 30-day half-life on old entries
  • MMR re-ranking — diversity-aware results
  • Multilingual — 8 languages, CJK tokenization
  • Grounded REM backfill — validated observations → priority memory
  • Per-agent isolated memory spaces · daily logs
  • Git-backed — every write committed, diffable, auditable
  • Search by filename / path · self-healing multi-process index
  • Triggers & scheduling
  • Cron scenarios · diff-based reconciliation (no nuke-and-pave)
  • Natural-language schedules (“every weekday at 9am” → cron)
  • Heartbeats — periodic agent prompts, no planning overhead
  • Proactive grant provisioning — pre-approved before the run
  • Webhooks — HTTP→Queue bridge (Hono, Bearer auth)
  • Event-driven hooks — react to run.completed, task.failed, custom
  • Workflow-scoped hooks — fire only for one run, auto-unsubscribed
  • Self-scheduled wake-ups — an agent books its own one-shot follow-up
  • Self-improvement
  • Eval-triggered analysis — threshold-gated to weak runs
  • Suggestions ship as a PR via git worktree
  • Closed-loop A/B validation against the baseline on held-out inputs
  • Auto-revert PR on regression (merged by a human)
  • Anti-reward-hacking fence — can’t edit its own grader
  • Lessons distilled into memory — the same failure isn’t re-learned
  • Cross-scenario failure taxonomy — one root-cause fix, not N
  • Delegated auto-accept — hand the Accept card over: N uses, a TTL, instant revoke. The engine can never ask for it
  • Surfaces & control plane
  • Telegram bot — commands, wizard flows, inline keyboards
  • Mobile-ready control plane — approve a grant from your phone
  • Agents Matrix war-room — many live agents in a split grid
  • Unified activity stream — every action, searchable, replayable
  • Cost dashboard with plain-language insights
  • Scenario authoring UI — no hand-edited YAML
  • Blueprint wizard with an in-editor AI guide chat
  • Artifact browser · MCP server (stdio + HTTP)
  • Topic-per-agent — Telegram forum topics as delivery lanes · thread-scoped agents
  • Secretary mode — the bot answers your Telegram DMs as you: no bot chrome, and every tool call pinned to that one chat
  • Ops & infrastructure
  • One Docker image → 6 services (entrypoint routing)
  • omnislash dev / start / prod · doctor · upgrade · db migrate / status / generate
  • Versioned DB migrations — engine + brain lines, advisory-locked runner, applied on every deploy
  • Record & replay any run deterministically — zero tokens
  • Auto-TLS via Caddy · subdomain routing
  • Grafana + Prometheus + Loki + Sentry + Bull Board
  • Distributed rate limiting across bot / worker / mcp
  • Service discovery with health heartbeats · crash detection
  • NocoDB database browser · dead-code detection (knip)
  • CI/CD: changesets · multi-arch image · auto-upgrade PRs
  • Integrations (80+ tools)
  • Google Workspace — Calendar (multi-calendar, full event CRUD), Gmail, Drive, Tasks, Sheets
  • Telegram MTProto — search, dialogs, history, bulk export
  • Notion · Figma
  • Social — Twitter, LinkedIn, Instagram, Reddit
  • Search — Tavily, DuckDuckGo, Perplexity
  • Media — OpenAI image gen, YouTube, ElevenLabs
  • Data — SEC filings, YCombinator, Outscraper (Google Maps)
  • n8n — 8 workflow-automation tools
  • OAuth store with background token auto-refresh
  • Integration Kit — declare auth + webhooks + tools, engine provisions
  • context.notify — brain tools send through the engine’s transport (rate limits, retries, formatting)

The unglamorous half of that list, photographed — the boss run, both roster layouts, the cost controls, the artifact store, the raw event log, the environment and the settings page.

  • The boss-run banner: a time-boxed autonomous session with a visible kill switch.
  • The agent roster as a dense list — status, model, source, cost per agent.
  • The same roster as cards — the browsing layout for a smaller fleet.
  • The same cockpit re-pointed: 90 days of tokens by week, pivoted per agent.
  • Every artifact agents produced, content-addressed and publishable by URL.
  • The raw engine event log — the audit trail behind every screen above.
  • Effective environment configuration, with secrets masked.
  • Operator settings for the control plane itself.

Still not the whole list — the exhaustive inventory lives in docs/features.md, and every screen of the control plane is one click away . Bring me one operation →

Bring me one recurring operation. I'll show you the run.

Pick one operation that should run itself. Tell me what it is, who owns it today, and where it breaks. I'll map it to a brain and a scenario and walk you through how it runs — durable through a crash, gated at every permission, graded against a definition of done. I build these, and I built the runtime they run on.

Prefer to dig in first? See the packages & image

Send me the one operation: what it is, who owns it today, and where it breaks. It comes straight to me — I read every one and reply myself.

Talk to me about your operation
hi@omnislash.ai