We're not making another agent that's merely stitching things together. Our inspiration came from our frustration with the status quo.
The Permission Dilemma
Personal agents are giving people two hard choices: let it be mighty – powerful enough to literally ruin your life – or let it be tamed, unable to reach the right contexts and waiting for you to feed it by copy-pasting. It's not even about what agent software you're using, although that matters. It's about how you want to use it. Even a general-purpose agent, locked inside a sterile container, turns isolated. And then it's on you to configure the working context from scratch.
That's the dilemma in one sentence. An agent that can do real work holds real power, and the way we grant that power today is either too coarse to trust or too fiddly to use. We either give it everything and flinch, or we gate every step and grind to a halt. Neither of those is permission. One is abdication; the other is theatre.
The problem was never the model. It was who holds the keys, where the work runs, and whether you can take the keys back.
Agents on Your Own Machine
Using universal agents like OpenClaw, or those coding agents, is perfectly fine for a lot of scenarios – building your open-source projects, or working on commercial software where the company treats your work as basically a chore. Their security controls are evolving, but it's strictly in private, single-user scenarios where you own the entire blast radius, and you are the only person responsible for outcomes. Practitioners aren't conservative, timid, or ignorant – they know the operational and security risks all too well, which is why such agents remain barred from real collaboration and multi-user environments.
Start from a different premise: the agent runs on hardware you own, beside the work it is meant to do. Nothing about an agent requires a data centre. The reason it ended up in one is billing, not capability.
On The Authorisation
Authorisation is the whole game. Who may do what, to which resource, on whose behalf, for how long – if you get that right, the rest is plumbing. The mistake is treating authorisation as a one-time setup step: a scope you tick once at install and never think about again. Real authority is granular, situational and short-lived, and it should feel that way to use.
I'm a fan of Auto mode when I'm building things alone, but I won't risk it running in a Slack group.
The Moment You See [y/N], You Have Already Lost Control
By the time an agent interrupts you to ask Allow this command? [y/N], it's very likely that it has already done ambient reconnaissance across your environment, files, and state – otherwise it would render itself useless and just ask for endless ls commands to figure out the missing pieces. Now you're left as a fatigued code reviewer trying to decipher what irreversible side effects it might trigger, in some unreadable one-liner bash command.
Even if you're a bash hobbyist and you read those commands perfectly well, you'd still probably fall for convenience. This is Confirmation Spam ([y/N]). Prompt fatigue induces learned helplessness. Developers rubber-stamp actions mindlessly just to unblock the tool, destroying the entire security model.
Can We Accept Explicit Authorisation in Advance?
Instead of runtime negotiations and prompt spam, authorisation belongs up front – established through explicit, bounded capabilities minted before anything touches a shell. Yes, this brings you to something like a whitelist, which doesn't sound much better than popping confirmations. But collaboration is the game changer.
Consider how you actually coordinate work within a group of humans. You assign roles and clear remits. When you delegate a task to a teammate, they do what they're allowed to do; if they hit a wall, they ask for an escalation. A bounded artefact – a link to a ticket, a branch to review, a scoped database dump – and you expect them to operate within that exact blast radius. Real workplace trust is cooperative and capability-driven: scoped, ephemeral, and bounded by default.
More granular config dialogs, an LLM-decided strategy, or louder confirmation popups won't fix this. A collaboration model will. Treat agents like coworkers: give them bounded, explicitly scoped capabilities for the task at hand, let them execute without ambient privilege, and shut the door behind them when they're done.
Agent Cluster Theatre (Yes, They Are Personal)
Agent swarms – often sold as autonomous "AI teammates" – are a sensible engineering technique for speeding up work and exploring options in parallel. Marketing aside, though, swarms are simply parallel search. Calling that a digital squad of artificial colleagues with cartoon avatars is pure theatre.
Treating agents as human coworkers dodges a basic problem: artificial teammates have no skin in the game. As Diogo Almeida pointed out, models trained to please human evaluators excel at plausible, confident nonsense rather than sound judgements. In a single prompt, that eager-to-please behaviour is merely annoying. Inside an automated swarm, it turns "peer review" into an echo chamber – ungrounded models reinforcing each other's confidence, nodding along with flawed assumptions, mistaking polite agreement for consensus.
Pretending bots are coworkers is no substitute for solid systems design. Agents are not phantom colleagues sitting in a cloud meeting room; they're personal tools running on people's own machines. Real consensus only happens between people and their devices, backed by explicit permissions and real-world stakes.
The SaaS Trap
There is a well-worn path from here, and it leads to a product that looks like every other one: sign up, connect your accounts, paste in your keys, and let the service run your agents for you. It's a comfortable business. It's also a trap, and it fails in three predictable ways.
At Best, They Fail In Real Messy Workflows
Real creative work is fragmented across private repositories, half-documented internal scripts, finicky terminal configurations, staging bastions, and weirdo tools – nothing like the neatly manicured demo sandboxes. Sterile SaaS silos choke the moment they collide with this messiness. The creativity is entirely about the half-baked intermediates, and that's not something you can easily put into an SOP for a workgroup to fill out forms about. An agent reaching in from a cloud sees none of that; it sees the tidy API surface the integration exposes. The moment the task leaves the happy path – which is immediately – it's working from a model of your workflow rather than your actual workflow.
Data Given For Free
To make these remotely hosted agents remotely competent, vendors demand that you pipe in operational context: upload files to cloud workspaces, connect to third-party services. The moment you comply, you hand over everything that matters. Your proprietary source code, internal schemas, account access, confidential customer records – vacuumed up as vendor telemetry, diagnostic residue, and raw training fodder to sharpen a model someone else charges you to query. And if you want it to be even more useful, you give it a computer (which basically means a graphical desktop experience) and you log into your day-to-day websites in it. That's up another level entirely.
You Don't Need Cloud Orchestration
The big players wanted to make agents sound like a miracle, so they delegate all the work to their cloud orchestration services. Open the app, send some instructions, things are synced between devices. But that's the only justification I can make for it. On top of the data hand-in problem, it comes with wrong decisions piling up unnoticed and hard to abort. The rest – syncing, shared context, team tool usage – is not tied to cloud orchestration. What's valuable in the cloud is the context, literally. And that syncs perfectly well without anyone's orchestrator sitting in the middle.
The Core Vision & Solution
So we've said two things. Authorisation should work the way it does between coworkers: you hand someone a bounded thing and they act inside it. And what's worth keeping from cloud workspaces is the shared context. Put those together and the architecture falls out. Ask who can actually mint that bounded thing – only the person who already holds the access, on the machine where it lives: my repo checkout, my staging credentials, my calendar. A cloud orchestrator that wants to hand out slices of my access has to hold all of it first, which is exactly the ambient privilege we've been trying to get rid of. So orchestration stays with each person, on their own device, and what travels between people is the conversation, the grants, and the results.
Grants That Look Like Delegation
You grant a specific teammate a specific action for specific conversations, narrowed strictly to what the task requires – read the folder but don't write to it, or use these three tools rather than the whole server. Everything else is denied by default. Your machine checks the grant each time the action is called, so revoking it takes effect on the very next call without any token out in the wild to chase down. Anything you'd rather inspect first can require explicit approval: the requesting agent pauses, and you answer directly in the thread. That's the escalation path.
(Almost) No Remote Agent Cluster: Local Orchestrator, Device is the Cluster
Your agent runs on your device, next to your tools, using whichever model you choose. When someone else's agent needs something from your machine, your machine runs it under your grants and returns the result. Machines communicate peer to peer. The relays in between merely pass along encrypted traffic they can't read – the exact same role Syncthing's relays play – and you're free to run your own. Files travel directly between the two machines involved, fully encrypted, and remain temporary unless someone explicitly saves them to the conversation. There's almost no remote cluster because there almost never needs to be one. Your fleet is your laptop, your phone, and the machines of the people you're working with. That is the cluster.
No Phantom Identities
There are no bot accounts. Every agent runs on someone's physical device, and devices only trust each other after one person invites another. An agent can reach only what its owner can reach, plus whatever actions others have explicitly granted that owner – so every action it takes traces directly back to a human who agreed to it. Hosted bots, by contrast, usually act through a static app token whose broad permissions were fixed at install time, regardless of who's asking. When something acts in KeepTalking, you can say whose device it was and which grant let it. Because there is nothing else it could have been.
What It Feels Like
Slack-Style Threads, in Our Own App
KeepTalking is its own app: Slack-style threaded conversations where people and their agents talk in the same place, grouped into threads by topic automatically. Nothing goes through Slack. Each conversation picks its model – a hosted provider, an OpenAI-compatible endpoint your org runs, or Apple Intelligence on device. With a self-hosted or on-device model, nobody outside the conversation ever reads its content.
The interface disappears, and what's left is the work and the people doing it. The thread is also where permission happens – where an agent asks for scope and you widen or refuse it in line, where the whole history of who did what and who allowed it lives on your devices rather than in a vendor's logs.
An Example
A deploy to Jun's staging machine has failed. Mia opens a conversation with Jun, who owns staging, and Lena, who has the service checked out. Jun grants Mia his log-reading script for this conversation only; Lena grants read access to her checkout. Mia's agent pulls the recent errors through Jun's machine, finds the code path in Lena's, and posts its guess in the thread. When it wants to restart the staging worker, Jun gets an approval request right there. Afterwards, Jun revokes the grant. Mia never held a staging credential, and nobody had to upload logs or code into a workspace to make this work.
Mia mints a scoped grant: Jun’s node may ask Lena’s to read the failing deploy’s logs — this thread only, expiring on its own. She signs it with her key; nothing has run yet.
Mia's Laptop
Lead · coordinator
- grant signed with Mia’s key
- scope + expiry in local DB
Jun's Machine
Staging · where it failed
- node keypair
- the staging failure, still unexplained
Lena's Laptop
Codebase · source of truth
- the whole repository
- action defs registered locally
- capability token
- scope: read-logs
- expiry
the codebase, the logs, every model key
Nothing here required a server to hold the repo, the logs, or a standing token. The grant was minted, scoped, escalated in the thread, spent locally, and revoked – and when it was revoked, it was gone, because there was never a second copy of it anywhere else.
Principles
If you take nothing else from this, take these five. They are the whole argument, compressed – and they are a call to arms as much as a specification.
Your machine is the runtime
01Agents run where the work and the data already live. The device in front of you is the cluster – not a rented one somewhere you cannot see.
Grants, not roles
02Permission is explicit, scoped, granted in the moment and revocable in the next. No inherited role quietly hands anyone a capability you never considered.
The wire is sealed
03Peers negotiate a direct path and talk straight to each other. Nothing in the middle is in a position to read the traffic – or to arbitrate it.
No phantom identities
04Every actor is a real person or a device they own. There is no service account standing in for a human, holding permissions nobody remembers conferring.
Deletion is real
05Your contexts, threads and grants live in a database on hardware you own. When you revoke or delete, there is no cloud copy left to outlive the work.
Build agents that run where you are. Grant power the way you would delegate it – out loud, narrowly, and only for as long as it is needed. Keep the work, and the record of the work, on the devices of the people doing it. That is zero-cloud, and it is not a limitation. The cloud is something you may choose, never something you must accept.