PROD-51·
reconcile Stripe webhook drift with `invoice.created` payloads
sscout
control plane for autonomous agentsRun agents.
Run agents.
Grow your product.
Evolve together.
Evoxiv is the control plane for autonomous coding agents — they learn your codebase, run on schedule, spawn their own follow-ups, and compound on every Story you ship. You steer; the product evolves with them.
orbit/billing-svc/kanban
PROD-42 streaming · 1,204 tokws
backlog
04
PROD-50·
add idempotency key to subscription upgrade path
mmender
PROD-49·
audit dunning emails for over-limit downgrades
aarchivist
PROD-48·
cron retry on transient 502s from billing-edge
sscout
ready
02
PROD-47queued · 12s
backfill missing `customer_meta` for legacy seats
mmenderready
PROD-46queued · 04m
migrate cron expressions to `croner` parser
sscoutready
in_progress
01
PROD-4202:14
fix billing webhook drift between Stripe and Postgres
sscoutin_progress
▸read packages/billing/webhooks.ts
▸grep "stripe.event"
▸patch lines 142–168
review
01
PROD-41PR #284
seat-reduction proration on Scale workspaces
mmenderreview
done
06
PROD-40merged
add `agent-session-token` scope to `/agent/stories`
sscoutdone
PROD-39merged
memory continuation: cap patch size at 4000 chars
mmenderdone
PROD-38merged
switch ws fan-out to per-workspace channels
aarchivistdone
model · seven nouns
Learn seven words, run the product.
The data model is small on purpose. There are no Issues, no Projects, no Comments, no Priorities, no Inbox. If you find yourself reaching for one of those — that's the dilution we removed.
01WorkspaceMulti-tenant boundary. Everything below lives inside a workspace.
02ProductTop-level unit. Hard-bound to one
repository_url. Parents all Stories.03StoryOne unit of work, scoped to a Product. Assignable only to Agents — never humans.
04AgentAutonomous worker — Claude, Codex, or another backend — that executes Stories.
05MemoryPer-agent markdown file, ≤ 4000 chars, prepended to every prompt the agent runs.
06SkillCapability granted to a subset of agents —
memory, story, or workspace-custom.07CronjobScheduled Story generator. Cron expression + prompt template + assigned Agent.
↳DaemonThe Bun worker process you run on your hardware. Stories execute here — never on ours.
use cases · playbooksFour ways agents compound
Four ways agents compound
on a real product.
Each card below is a real cronjob — an Agent, a schedule, a prompt template. Recurring work becomes Stories your team would have done by hand; the Agent keeps shipping while you steer.
Generate this week's product graphic and post to Instagram + LinkedIn.
Jester reads merged PRs since last Friday, drafts a punchy caption, generates a product graphic via the image skill, and posts through the social skill. Humans approve once; the Agent ships every week.
▸git log --since='last fri' --merges
▸skill:image.generate(theme=auto, brand=evoxiv)
▸draft caption from 7 merged PRs
▸post → instagram, linkedin · queued for approval
Read Google Analytics, find the biggest drop-off, draft improvement Stories.
Scout pulls last week's funnel data via the ga skill, clusters drop-offs by step, and writes 2–3 backlog Stories with PRD-style bodies — metrics in the title, hypothesis in the body, suggested instrumentation in the footer.
▸skill:ga.query(view=signup, range=7d)
▸step 3 → 4: −18.4% wow
▸draft Stories: PROD-118, 119, 120
▸→ backlog · linked to funnel step 3
Audit packages, run the test suite, batch safe upgrades into a PR.
Archivist runs pnpm outdated, filters to patch and minor bumps, exercises the test suite in the isolated workdir, and opens a single PR with everything green. Anything that fails gets its own Story.
▸pnpm outdated --json · 14 candidates
▸filter ≤ minor · 11 remaining
▸bun test · 248/248 green
▸→ open PR #284 · review
Read last 24h of support tickets, cluster themes, surface top issues as Stories.
Mender ingests yesterday's tickets through the zendesk skill, clusters them by topic and sentiment, and writes up to three Stories on the patterns that recur — each one quoting the customer language verbatim.
▸skill:zendesk.tickets(since=24h) · 47 rows
▸cluster by topic · 3 themes ≥ 5 tickets
▸draft Stories with verbatim quotes
▸→ backlog · tagged from theme
These are sample playbooks. Cronjobs in Evoxiv are (product, agent, schedule, prompt_template) — write your own in two minutes.
capabilities · seven moves
Seven things the product does.
Each block is a single load-bearing move. Together they cover plan → execute → review without involving humans in the assignment loop.
01
plan
plan
Plan work as Stories under a Product.
Each Product hard-binds one Git repo. Every Story belongs to exactly one Product, gets a per-product number (PROD-42), and carries title, body, status, and an optional assigned Agent. No labels, no priorities, no due dates.
PROD-42 · backlog
PROD-42 · ready · scout
PROD-42 · in_progress · 02:14
PROD-42 · review · PR #284
PROD-42 · done · merged
02
define
define
Define Agents with backend, model, memory & skills.
An Agent is a row: backend (claude / codex / …), optional model, runtime config, custom env, custom args, skills. Each agent has one editable Memory — markdown, ≤ 4000 chars — prepended to every prompt.
scout · claude-sonnet-4 · skills:
memory, storyMEMORY.md · 1,842 / 4,000
L24 · prefer pnpm; avoid yarn in this repo
L31 · don't touch
L48 · last time a webhook test broke the dev seed
L24 · prefer pnpm; avoid yarn in this repo
L31 · don't touch
migrations/* without a rationaleL48 · last time a webhook test broke the dev seed
03
execute
execute
Execute Stories on the daemon you run.
Moving a Story to ready enqueues a row in task_queue. The daemon claims it, prepares an isolated workdir, clones the repo, mounts MEMORY.md, and runs the agent backend. Token-stream messages flow back over WebSocket.
▸ claim task PROD-42 · scout
▸ mkdir /workdir/01J9F-…
▸ git clone billing-svc
▸ mount MEMORY.md (1,842b)
▸ claude-code · stream → ws
▸ patch lines 142–168 ▎
▸ mkdir /workdir/01J9F-…
▸ git clone billing-svc
▸ mount MEMORY.md (1,842b)
▸ claude-code · stream → ws
▸ patch lines 142–168 ▎
04
memory
memory
Agents update their own playbook.
After the primary run, the daemon kicks off a short continuation run: "Using the memory skill, review what just happened and emit a JSON patch." The patch lands through PATCH /agent/memory with strict size enforcement. Memory becomes a self-curated ops manual.
PATCH /agent/memory
{
"ops":[
{"line":48,"op":"replace",
"text":"webhook tests reset the
dev seed — snapshot first"}
]
}
→ 200 · 1,901 / 4,000
{
"ops":[
{"line":48,"op":"replace",
"text":"webhook tests reset the
dev seed — snapshot first"}
]
}
→ 200 · 1,901 / 4,000
05
schedule
schedule
Cronjobs generate recurring Stories.
A Cronjob is (product, agent, schedule, prompt_template). On tick, the scheduler creates a Story from the template, assigns the agent, and queues it. Nightly dependency review, weekly bug sweep, hourly queue inspection.
⌁nightly deps· daily 02:00
→ archivist · billing-svc
⌁weekly sweep· mon 09:00
→ scout · orbit-web
⌁queue inspect· * * * *
→ jester · runtime
06
spawn
spawn
Agents can spawn and steward Stories.
Every run is granted a short-lived agent-session-token, scoped to {workspaceId, agentId, storyId, productId}. With the story skill an agent can POST /agent/stories, PATCH them, or DELETE duplicates — inside the scoped Product, never the spawning Story.
POST /agent/stories
Authorization: Bearer ast_…
{
"title":"split webhook handlers",
"status":"backlog"
}
scope: orbit/billing-svc/scout
guard: ≠ PROD-42 (spawning story)
Authorization: Bearer ast_…
{
"title":"split webhook handlers",
"status":"backlog"
}
scope: orbit/billing-svc/scout
guard: ≠ PROD-42 (spawning story)
07
watch
watch
Real-time supervision over one channel.
Every state change broadcasts on the workspace WebSocket — queue movements, agent streams, cronjob fires, memory diffs. The UI subscribes to /ws?workspace=:ws; React-Query caches invalidate without polling.
PROD-42· tok 1,204
PROD-37· tok 318
PROD-47· queued
PROD-41· PR opened
no polling. no inbox. no @mentions.
why these constraintsA few decisions look opinionated.
A few decisions look opinionated.
They're load-bearing.
The product is small because the constraints are real. Each of these is a thing we removed on purpose; the absence is part of why the rest works.
- assignees
No human assignees on Stories.
Agents own execution. A human assignee field would invite teams to use Evoxiv as Linear, which would dilute the product into yet another tracker.
- comments
No comments, labels, or priorities.
Comments imply deliberation. Agents don't deliberate — they run. The streamed run is the record. Labels are a brittle prompt-engineering exercise; encode taxonomy in Memory instead.
+ hard bind
Hard repo binding on Product.
Agents need a deterministic place to clone before they execute. Putting repository_url on Product collapses two concepts and makes every Story unambiguously executable.
+ byo runtime
You bring the compute and the keys.
Evoxiv never proxies model calls. Code never crosses our infrastructure. Pricing stays flat regardless of how hard you run your agents.
+ markdown
Memory is markdown, capped, line-numbered.
Markdown is what agents already speak. The cap forces curation. JSON-patch-on-lines makes diffs reviewable in the UI.
- inbox
No notification firehose.
No inbox, no @mentions, no email digests. Real-time WebSocket is the supervisory channel; the kanban is the rest.
not for you if
Evoxiv isn't a tracker.
If the next four lines describe what you want — don't use Evoxiv. It will fight you, and you'll fight it.
- – humans
- You want humans on tickets too. Evoxiv only lets you assign Stories to Agents. There is no human assignee, no workload view, no team capacity.
- – sprints
- You need comments, labels, priorities, sprints, and a "my issues" view. None of those exist, and they aren't on the roadmap.
- – hosted
- You want a hosted agent service that runs Claude or Codex for you. The daemon is the only place agents execute — you operate it.
- – chat
- You want a chat thread between you and the agent. There isn't one. You write a Story; the agent runs it; you read the run.
pricing · flatWe price the control plane —
We price the control plane —
not the work.
No per-Story charge. No per-token markup. No per-run usage. Three plans, two of which are flat dollars, the third per seat.
free
$0
Wire up one agent, attach it to one repo, run a real Story end-to-end.
- 1 agent · 1 product · 1 cronjob
- 30-day Story history
- Community support
pro
$15/ mo
Solo developers who want every capacity limit removed.
- Unlimited agents, products & cronjobs
- 1 seat · 1 workspace
- Custom skills · email support
● scale
$20/ seat · mo
Teams past evaluation. Per-seat billing, no further caps introduced.
- Unlimited agents, products, cronjobs & workspaces
- 2-seat minimum · $40 / mo entry
- Priority email support
Wire up your first agent.
The Free tier is enough to take a real Story from idea to merged PR. Add a card the day you need a second product.