Your decisions, a team that keeps them,
and the proof.
writ runs a team of AI agents on a developer’s own machine and keeps every one of them working from your decisions. When one is ignored, the action is refused, the approved way is handed back, and both are recorded.
Each developer now runs an engineering team.
- Builders, one per project. Each works only in its own project, with its own history.
- Test platforms, one per language. Shared by every project in that language, so results come from real suites.
- An independent reviewer. Its own workspace and method. Every finding names a concrete failure and an exact location. It never edits code.
- writ between them. Who owns what, who asks whom, and what is still open.
Separation of duties, built in. The agent that writes the code never marks its own work.
Your decisions, in front of the agent on every prompt.
writ restates your team’s settled decisions, in your words, with every request, for every assistant. They sit beside the work instead of fading as the session grows.
- Captured as decisions, not a rules file. A cost found later is added without reopening the decision, so the agent never relitigates it.
- The same decisions across every agent and assistant, with guidance that can be tagged for one assistant only.
of an instruction’s effect was gone after 2,048 tokens of unrelated work.
In our testing, we placed an instruction in an AI’s context, let it work on something else, then measured how much still applied.
A record the agent can’t rewrite.
The team’s work lives outside the agents, in a durable record kept for each project. Newer entries supersede older ones and both stay, so you can always answer what was decided, and when.
Decisions
In your words, with their full history.
Open work
Carried across sessions and between agents. “Done” is decided from the record, not the agent’s report.
Facts and handoffs
Recorded rather than guessed. When a session fills, unfinished work is saved and the next one picks it up.
Your decisions
Small, settled and always in front of the agent.
Your documentation
Guides, runbooks and API references indexed on the workstation. Every answer points to the file and line it came from.
One governed front door for every agent, project and assistant.
Agents reach approved tools, the record and each other through one entry point, shared by every project on the workstation and every supported assistant.
| A fleet of tool servers | writ’s desk | |
|---|---|---|
| Setup | Configured per assistant, per server. | Installed once; the same from Claude Code, Copilot and Devin. |
| Adding a tool | Often a reconnect, and a slot in a capped tool list. | Available on the next request. |
| Between projects | Each agent works alone. | Requests and contracts between projects stay open until answered or declined with a reason. |
| Testing | Whatever the agent decides to run. | Each project’s own suite, on the shared platform for its language. |
| Governance | Each server approved separately. | One door, every request recorded. |
Agents that start themselves, clear and rehydrate, and pick up after a restart.
This is the force multiplier: the team keeps moving while your attention is elsewhere, so you direct the work instead of carrying it from window to window.
Work wakes the agent that owes it.
A request from another project, or open work left behind, wakes that project’s agent and tells it what’s waiting.
Clear and rehydrate. Never compaction.
Before a session fills, the agent writes what’s unfinished to the record; writ clears the session and rehydrates the new one from the record. Nothing is silently lost to a summary.
Stop everything safely, then carry on.
One command has every agent finish its edit, record its open work and stop. After the restart, agents with open work pick it up.
Every wake-up is on the record.
Each one says what it was about, and the agent confirms it was received.
A customer posts a problem. The agent that owns it gets to work.
Connect your community’s Discord and writ turns support posts into work: each post is filed to the project it is about, and that project’s agent is started to handle it. No triage queue, nobody copying text from Discord into an editor, and no bot that answers from a script. The agent holding the conversation is the one that knows the code.
Filed to the right project
Bug reports, feature requests and support questions are routed by server, channel or tag, screenshots included, filed once. Later replies join the same thread.
The owning agent gets to work
An idle agent is woken with the whole post in hand, screenshots open in front of it. No editor open for that project? writ opens one.
A conversation, then a fix
The agent asks the customer what it needs in their own thread, and their answer comes straight back to it. It reproduces the bug, fixes it, and the release notes go to the project’s channel.
Support from the people who built it
Questions are answered by the agent that works in that codebase every day, so the answer is specific: what the setting does, why it failed, what to change. A vague report becomes a precise one in a few exchanges.
Bugs handled, not just logged
A report is not a ticket waiting for a sprint. The agent takes it as work: reproduce, fix, test, release, tell the customer. Ones that need a decision are filed for a person.
Your community is on the record
Every post is stored and searchable, so an agent can ask what customers have said about a feature before changing it. General chat is kept and queryable, never turned into work.
Under your rules
Support work runs under the same decisions, laws and approvals as everything else. Only a person approves a change to what a test expects.
Polite by construction
The bot types in Discord in two places only: a question in the customer’s thread and a release note in the project’s channel. It never mentions anyone and never posts internal discussion.
No flood on day one
Connect a server with years of history and only new posts become work. With Canon, one community feeds the right projects across the organisation.
Handing the post to a newly opened editor session automatically is in final testing.
The agent can ask. Only a person can approve.
An agent under pressure will reason its way past a failing test: delete it, or change the expected value to match the broken code. writ refuses the edit and files it for a person.
Weakened test caught
A failing test’s expected value was changed from 22,500 to 25,000, the number the bug produced.
The agent explains
One plain sentence. You decide from that, not from 100 lines of diff.
A person approves, or not
Approved: that exact edit goes through once, recorded with the approver’s sign-in. Rejected: the agent is told not to try it again.
New tools need a yes
A tool runs only after a person approves its exact command. Change the command and the approval is cancelled.
One queue
Everything waiting on a person, from every agent on the workstation, in one list, right in the editor.
Four eyes, built in
The agent that makes a change never approves it. No approve-all.
When a decision is ignored, the action is refused.
Laws check what an agent does, and what it says it has done, at the moment it happens, and decide from the record, not from the agent’s memory.
It holds the agent to what it says.
A claim with nothing behind it is refused. So is “done” while assigned work is still open, or reopening a settled decision.
A refusal comes with the way through.
You author the rule and the approved alternative. The agent takes the approved path and the work continues.
Every agent stays in its lane.
A builder works only in its own project; the reviewer writes findings and never edits code.
Enforcement is verified, not assumed.
writ proves its rules are live on each machine. Anything it couldn’t check is reported as unmeasured, never compliant.
See a team at work, and a refusal.
A live demo on your own workflow. Technical deep dive available under NDA.