Lab notes
What we learn running agents, written down.
We run agents in real work, mostly our own, and write down what we learn. Where a note reports a test we ran, it gives the date. The rest are working ideas. None are peer-reviewed papers.
Six questions we test in real work.
These are the six questions the lab works on. We test each one in real work, mostly our own, and write down what we expected, what broke and what we changed. The notes below are working notes, not peer-reviewed papers.
IdentityBetween agents
Which agent is really answering?
On 1 September 2026 we sent one message to eleven of our agents. Every reply came back properly signed, yet four answered as the generic agent they were built from. Once each agent loaded its own role on every turn, all eleven answered as themselves.
In the Portal, every agent signs in as itself, with its own login.
Read the note: Signed correctly, answering as someone else
PermissionsYou to an agent
What is an agent allowed to do for you?
Don’t hand an agent a password. Hand it a narrow permission for one job, one you can take back at any time. A mini app can be stricter than that permission, never looser.
In the Portal you choose, for each agent and each mini app, whether it may add, read, change or delete.
Read the note: Give agents a permission slip, not your password
DecisionsAn agent to you
When should an agent stop and ask?
Asking a person is part of the system, not an interruption. You approve exactly what will be sent. If the agent changes the email after you say yes, it has to ask again.
This became Operator Inbox: every agent’s questions land in one list, in front of one named person.
Read the note: Asking a person is part of the system
MemoryPeople and agents
What should people and agents remember together?
Good memory has an owner, a source and a place to come back to. It should still be there after you switch AI model, agent app (Claude Code, Codex) or chat.
This became Knowledge: memory where every note has an owner and a source, kept on the client’s own server.
Read the note: Memory that survives the model
HandoffsBetween agents
How should agents hand work to each other?
When one agent hands a task to another, three things must go with it: what it’s allowed to do, what it knows, and who answers for it. A person should be able to check all three.
Still open. No lab note yet.
ProofPeople and agents
How do we know it actually works for people?
“The code exists”, “the tests pass”, “it’s installed”, “it ran for real” and “a person used it” are different claims. We always say which one we have.
It’s how we sign off every install, ours and yours.
Read the note: What counts as proof that an agent tool works?
When is it really done?
- 1Watch
See how people really work with agents, starting with our own.
- 2Pin it down
Find one problem that keeps coming back, and name it.
- 3Build
Make one mini app that fixes that problem and nothing else.
- 4Prove
Use it in real work before we call it done.
We check every version we ship, and every client install, against six levels.
- 1Written
The code exists.
- 2Tested
Automated checks pass.
- 3Visible
A running agent can find it.
- 4Installed
An exact version is running, healthy, on a real server.
- 5Ran for real
One real job went all the way through, past every check it should.
- 6Used by a person
Someone finished the job it was built for.
“Passing tests and a person actually getting the job done are both good signs. They aren’t the same proof.”
Passing a lower step never proves a higher one. If a handover stops at “the tests pass”, it’s still a demo.
Lab notes
Signed correctly, answering as someone else
We sent one message to eleven of our agents. Every reply came back properly signed. Four answered as the generic agent they were built from, not as themselves.
“A signature proves who sent the message. Only the agent’s own instructions make it answer as itself.”
Why we build mini apps, not one big system
The goal is one agent that helps across all your work. We get there one small, checkable mini app at a time.
Asking a person is part of the system
When an agent’s next step really matters, a quick “ok?” in a chat isn’t enough.
Give agents a permission slip, not your password
The safe way to let an agent act is a narrow permission for one job that you can take back at any time.
Memory that survives the model
Your documents, where they came from, and where the work stands should still be there after you switch AI apps or start a new chat.
What counts as proof that an agent tool works?
“The code exists”, “the tests pass”, “it’s installed”, “it ran for real” and “a person used it” are different claims. We say which one we have.
Make every client install repeatable
The steps you repeat at every client should live in a shared, checked process, not in one engineer’s head.