FDEs and AI consultants
Every project starts with the same groundwork: memory, approvals, rules. Start with Knowledge, Rules & Approvals and Operator Inbox, and add Remote Setup before client four.
A research lab for human–AI interaction
We research how people and agents work together.
What holds up becomes an open-source mini app: memory, an approvals inbox, rules, a task board. You deploy the same setup to every client, on the client’s own server.
Message Eyal on WhatsApp. We book a call with you and your client: you hold the mouse, it goes live on their server, we film it, and it’s free for 30 days.
Agents got easy. Everything around them didn’t.
You can build the agent in an afternoon. Then comes the part you rebuild for every client: memory it can search, a way to ask a human, rules, a board for the work, connections. Each copy comes out a little different, and each one breaks on its own schedule when a token expires or an API changes.
Builders don’t make a new crane for every building. Neither should you.
You can build it yourself. Once.
Claude Code will write memory, an inbox and approval rules for one client in a week. By client four, the cost shows: four slightly different versions, no shared fixes, and a new security review every time. Build the agent. Don’t make the same bricks for the fourth time.
Your first client took three weeks of setup work. With the same mini apps, we expect your fourth to take a day. We’re filming installs to measure it, and we’ll publish the number we get.
| Built by hand | With mini apps |
|---|---|
| A slightly different version for every client | The same mini apps for every client |
| Fixes applied one client at a time | One fix reaches all of them |
| A new security story for each review | The same open-source answers, every time |
| Your private checklist, rewritten per install | Remote Setup’s plan, checks and record |
It’s open source, so you can read every line, fork it, or leave.
Every mini app started as a question.
We study how people and agents work together in real deployments, usually our own, and write down what we expected, what failed and what we changed. When a problem keeps coming back and is specific enough to solve cleanly, it becomes a mini app.
- 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.
Identity
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.
Lab note: Signed correctly, answering as someone elsePermissions
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.
Lab note: Give agents a permission slip, not your passwordDecisions
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.
Lab note: Asking a person is part of the system
“Passing tests and a person actually getting the job done are both good signs. They aren’t the same proof.”
Your next install can be in our next research paper.
Where you build it, where they use it.
The Portal
Where you run every client. Each client gets a workspace, and each workspace is a canvas.
- PlanDrag in the client’s agents and the mini apps they need. A wire from an agent to a mini app gives it access, with its own permissions. Mini apps wire to each other the same way.
- DeploySet up each mini app from the canvas and send it to the client’s server: review the plan, confirm.
- RunOpen any live mini app and see what’s running on each client’s server.
- ReuseExport the whole setup as one file. Client four starts from client one’s layout, and the security team gets the diagram.
The desktop app
A macOS app for the client’s people who work with the agents every day.
- Chat
- Where they talk to their agents. It pairs with the Portal using a one-time code, so it uses the agents and permissions you set on the canvas.
- Companion
- Builds a timeline of their day and gives gentle nudges when they drift off task.
- Listening
- Turns speech into text, so they can dictate to an agent instead of typing.
Claude Code, Codex and others connect with one link (an MCP URL). Switch agents any time. The memory and permissions stay.
Built for the people who deploy agents for clients.
Second-brain builders
You already sell structured knowledge. Knowledge is that offer rebuilt for agents: sources, revisions and cited recall, owned by the client.
Start with Knowledge (memory with sources), Scribe (reads chats into Knowledge) and Task Board (the work, in view).
Automation agencies
Flows are turning into agents. Add the approval step automations never had, and keep credentials in one place.
Start with Marketplace (connections and keys), Rules & Approvals (what agents may do), Operator Inbox (approvals to one person) and Evolving Workflows (repeat work, automated).
AI dev and product agencies
Hand over something that keeps running, and have answers ready for the security team.
Start with Live Artifacts (answers that stay live), Open Design (design with review points), Rules & Approvals (what agents may do) and Marketplace (connections and keys).
Buy it once.
Planning a setup in the Portal is free. When you bring a client, the mini apps are free for the first 30 days. After that you pay once per mini app per client workspace, for any number of agents. No monthly bill from us; the client only pays for their own server.
Which mini apps for which project