The Excellent Method
How we think humans and agents should share the work — and why the product is shaped the way it is.
The founder of Excellent · July 2026
There is one business. It should have one set of records.
Every company already runs on the same handful of things — the work, the pipeline, the people, the money. Most software chops those into separate apps that each keep a partial, stale copy and never quite agree.
We think that's backwards. There is one business; it deserves one designed set of records that everything else is merely a view of. What follows is what we believe, and why the product is built the way it is.
One record, seen across every surface — pointed at a single store.
Proof
Excellent is one integrated product — one process, one SQLite file. Not a suite of apps sharing an API.
[ 01 ]
Own the data.
A company is not a pile of apps; it's one set of records. Keep them yours, in one place, where everything — and everyone — can finally see all of it.
Your work, your pipeline, your people, your money — in most stacks these live in five products that each hold a slice and none hold the whole. We keep them as one designed set of records on your own machine.
Not to lock them away — so that everything, and every agent, can see all of it at once. Ownership here isn't a pitch about vendor lock-in. It's a plain fact, said the way Obsidian says it: the records are on your disk, in one store, and you decide what leaves it.
one file on your disk
data.db
Proof
Data at rest is local — SQLite on disk. No Excellent cloud tenant holds a copy. Sync is off by default. Attachments are stored by reference — it's every record, not everything.
[ 02 ]
Interfaces, not apps.
CRM, hiring, docs, tasks aren't bolted-together products. They're different views onto the same records. The shared design underneath is the point.
A CRM is a way of looking at people and deals. An applicant tracker is a way of looking at people and jobs. Underneath, it's the same people.
So we don't ship five apps that each define 'a person' their own way — we ship one deliberately designed schema and let each surface be a lens on it. A candidate is a person. A lead is one or more people. A résumé is an attachment. You change the lens, never the data.
Designed interfaces
One local data layer
people · organizations · money · work — one file you own
Proof
Candidates ARE people. A lead is one or more people, linked through entity_links. A résumé is an attachment. A note is a note. One directory, many views.
[ 03 ]
Agents are teammates, not a chat box.
An agent shouldn't live in a corner you copy-paste into. It should pick up work off the same board you do — and hand it back with evidence.
The industry's default is a chat window bolted to the corner — you ask, it answers, you paste the answer somewhere real. That's a demo, not a coworker.
Here an agent claims a task in the same column you would, moves it through the same states, and hands it back with a trace of what it did. You supervise one board, not two systems. The agent isn't a feature of the app; it's a participant in the work — and it uses the same tools you'd give a new hire.
Todo
In progress
claude-8df093
Review
handed back with a trace
Done
One board. A person and an agent work the same columns.
Proof
An agent's identity is derived from its process tree — not pickable, no environment override. It travels the exact same todo → in progress → review → done a person does.
[ 04 ]
No one approves their own work.
The load-bearing rule isn't about agents or humans — it's that neither gets to mark their own work done.
Every change moves through four states — todo, in progress, review, done — and a different identity has to verify it before it lands. This isn't a guideline you're trusted to follow. It lives at the data layer.
Ask to approve your own work and the system doesn't frown — it refuses. The same rule binds a person and an agent equally, and that equality is the whole trick: an agent gets to touch real work precisely because it's held to the exact check you are.
Todo
Work is defined.
queuedIn progress
A shipper claims it and does the work.
shipperReview
It hands off with evidence.
in reviewDone
A different agent verifies.
verifierProof
Self-verification is refused, not discouraged — the gate returns a hard failure:
{ ok: false, reason: "self-verification-blocked" }[ 05 ]
Measure before you mutate.
It's easy to “optimize” a process by changing it and declaring victory. We don't allow the leap.
Every agentic action is measured before anything is touched. A process is modeled as something you can evaluate, and a change only ships if it beats what it replaced — on evidence gathered offline, before it spends real money.
Even the optimizer is held to the gate: it can't promote its own work. And when a change misbehaves, a watchdog rolls the system back to the last known-good on its own. Improvement is a measurement, not an opinion.
Measure
Model as a workflow
Gated optimizer
last_good rollback
a change ships only if it beats what it replaced — on evidence gathered offline
Proof
The optimizer may not promote its own work. A self-healing watchdog rolls back to the last known-good. Evals run offline, before live spend.
self-promotion-blockedlast_good[ 06 ]
Local-first is a stance, not a feature.
Local isn't a vault. It's where the work is best done. An agent that can see all of it beats one squinting through five APIs.
'Local' usually gets sold as a vault — your data, locked away, safe. That's the small version. The real reason to keep the business close is that it's where the work is best done: an agent that can see all of it, in one place, does better work than one reaching through five APIs.
There's no server of ours to breach because there's no server of ours holding your business. Sync stays off until you turn it on. Telemetry is opt-in, anonymous, and scrubbed to nothing that identifies you. It's your machine — you decide what leaves it.
A database you own
Your whole business is a local SQLite file on your machine. No tenant, no upload, no lock-in — and it works offline.
Bring your own LLM key
You supply a Claude or OpenAI key. It's sealed on your machine and the agents bill to your account, not ours.
Encrypted at rest
Sensitive state lives in an encrypted vault with the key off-database, in your OS keychain — never written next to the data.
A signed audit chain
Every change is an event in a per-node hash chain with signed checkpoints. The history is tamper-evident by construction.
Open MCP server
Every operation is exposed over an open MCP server, so any agent — including your terminal Claude — can drive the same data.
Exportable, always
It's your data in an open format. Export the whole workspace any time — there's no door we can lock you out of.
Proof
Sync stays off by default. Telemetry is opt-in, anonymous, and allowlist-scrubbed. Integrations use direct OAuth — no third-party broker. You decide what leaves it.
This is how we'd run it.
None of this is a feature list. It's a way of working: keep the business close, let people and agents work it side by side, measure before you change anything, and never let anyone — human or agent — sign off their own work. If that's how you'd run it, you can run it here.