Every team that hands real work to an AI coding agent ends up asking the same thing: what can it do without me?
“Everything” is fast until the day it isn’t. “Nothing” means you’re back to doing the paperwork yourself. We wanted a clear line in between, one you can explain to a client in a sentence. This post explains where we drew it and why.
The rule: anything that leaves the building waits for a person
The agent does the record-keeping. It’s good at that, and nobody misses doing it by hand. It can:
- read a ticket and its full history before it starts
- search for earlier related work
- post progress as internal notes
- set and update delivery dates
- draft the resolution: root cause, what was done, how it was verified
- draft the release: summary, client note, security note
- record a deployment to an environment
Four steps are different. Each one is a promise to someone outside the team, and each one waits for an admin:
- Publishing a release.
- Sharing a resolution with a client.
- Sharing a file with a client.
- Sealing an evidence record.
A draft can be thrown away. A published release, or a note in a client’s portal, can’t be taken back. That’s the whole test: if a step is hard to reverse or someone outside will see it, a person takes it.
Why in the database, not in the prompt
You could write “never publish a release” into your agent’s instructions. Most of the time, it would listen.
“Most of the time” is not a control. Instructions get summarised away when the context window fills up. They get overridden by a confident-sounding request. They behave differently when you switch models. And when something goes wrong, “the prompt said not to” is a poor answer to give a client.
So those four steps are checked by the database itself. When a request comes in to publish a release or share something with a client, the database checks who is asking. If they aren’t an admin, the change is refused, no matter how the request was worded or which tool sent it. A clever prompt can’t talk its way past a database check.
The part people miss: whose access does the agent have?
There’s a catch, and we’d rather tell you than have you find it.
An agent connects to Pathledge with a personal key, and it works as the person who holds that key, with exactly their access. No more, and no less. Give your agent a key that belongs to an admin, and the agent has an admin’s access, gates included.
That’s why we take the next step seriously. At launch, agents get their own restricted identity by default, not a copy of yours. The four steps above stay locked to people. Raising a new ticket, replying where a client can see it, and closing a ticket will also wait for a person, as settings on the agent’s identity.
To be precise about today: those last three are written rules our agents follow, not database checks. We’re not going to describe a rule as a lock.
What this looks like day to day
In practice, the split feels like working with a quick, careful junior who writes everything down:
SD-1042 · Resolution drafted: root cause, what was done, how verified. Release 2026.10.2 drafted: summary, client note, security note. Waiting for an admin to publish.
You open the draft, read the client note, change one word, and press publish. The agent saved you the hour of writing. You kept the five seconds of judgement.
Every key is hashed, expires, and can be revoked instantly. Every key event is logged. Tickets an agent raises are labelled as agent-raised, so nobody mistakes them for a client request.
The line, in one sentence
Your agent drafts. You approve what ships. It’s the line we wanted for our own work, and it’s the one we’re building Pathledge around.
Pathledge is in the final phases of beta testing with three teams. If you want this line in your own workflow, join the waitlist. You’ll get one email when there’s news, and nothing in between.