Define the work before the automation
A desk is a standing piece of agent work for a business. agent-desk gives it a one-page desk.md, its own tables and a shared SQLite database. The agent reads the plan, works in the chat and uses a script to read and write the records.
I start with what the desk is for and how success is measured. Sales needs different records from SEO, but both need a way to show the work and ask for decisions. The plan makes that purpose explicit before the agent starts turning activity into a routine.
agent-desk is private for now. Keep the ongoing job, its current state and its approval rules together. A standing responsibility needs a record that survives the session.
Put the guard in the database
The database refuses a send that is neither approved nor earned through trust. It also refuses approval of a version nobody saw. The approval therefore belongs to the actual work under review, rather than a broad impression that something similar looked fine earlier.
The rules live in database triggers, so they apply whichever agent or person is writing. A playbook can explain what should happen, but the database enforces the guard when a write reaches it. The kit requires a test for every guard that fails without that guard.
Counted on 18 October 2026, 20 triggers and 28 tests guard the kit. The approval rules travel with the database when I put a desk into another project.
- Holds block work touching a person, address, domain or brand, including CCs.
- Locks stop work on something another person has claimed.
- An action cannot be claimed twice.
- Attempted work and the log cannot be edited.
Earn trust for a specific action
The trust ladder is specific to the kind of action, channel and identity. Approval of a reply is not blanket permission for every kind of message. I want a desk to learn a bounded job while keeping the person’s control over what it may do.
- Two coached drafts.
- Five clean approved ones.
- Then trusted, with every fifth action shown in full as a spot check.
An edit or refusal resets trust. Anything marked always-human never earns it; money and contracts stay with a person. Trust alone also does not authorise sending: the database needs current permission with the person’s words, scope, expiry and revocation.
Keep the people and promises together
The kit was rebuilt as an installable kit on 17 October 2026 at 15:16. By 10:30 the next morning, the business-development desk was in this site’s repo. A reusable plan and database gave that standing job somewhere to live.
Desks for the same business share a database, including people, contacts, holds, tasks and actions. Worktrees use the main checkout’s file too. Separate sessions therefore see the same history, rather than each building a private account of who has been approached or what was promised.
The business-development desk records companies, deals and meetings separately. A company’s relationship with the business and a deal’s stage answer different questions. A meeting needs an outcome in my words, a next step and a recap; I take every call myself.
Its working round checks measures and what is waiting for me, works through inboxes, records meetings and handles due tasks and follow-ups. New approaches come after that. The structure keeps an existing promise visible alongside the search for someone new to approach.
Make the stopping point part of the job
A name on a list is not a reason to write. The desk needs a named person, a problem that fits an offer and a reason to act now. Commercial mail, including prices, proposals, scope, contracts and invoices, always needs a person’s approval.
I judge the desk by whether the records support the next decision. Can I see what needs me, which promise is due and what happened to the last action? That is the standard to copy before adding more activity: a standing job that remains accountable to the person running it.