Autonomous internally, permissioned externally

Doing the work and finding the work are mutually exclusive. When you are inside a contract, a board seat or a client engagement, your pipeline dries up; when the work ends, the scramble begins. Every independent professional knows this, and the tools built to help were built for salespeople: a CRM you fill in by hand, job boards that surface volume rather than fit, outreach tools that send without thinking. So over the summer I designed and started building the thing I wanted, a system that discovers, researches, qualifies and drafts outreach for the opportunities that fit a portfolio career, continuously, in the background, while its owner is busy earning. I call it VenturePilot. It is not for sale and it is not finished; it is a private product for me and a few design partners. This piece is about the one design decision in it that I think matters to anyone deploying an agent, whether or not they ever see mine.

The rule

The system's constitution, the document that every later decision has to obey, has one line at its centre: autonomous internally, permissioned externally. Inside its own walls the agent may do what it likes within the budgets it is given. It watches approved sources, follows evidence trails to related people, companies, roles and events, deduplicates, scores every candidate for fit, risk, commercial value and effort, and writes a personalised first message grounded in evidence from my actual work. Then it stops. Nothing leaves the system, no email, no calendar entry, no application, no message to anyone, without a human approving the exact thing that will leave. Not "approve outreach to this company". This message, these words, to this person.

That distinction between inside and outside is the whole design. Everything the agent does internally is reversible, observable and cheap to be wrong about; a bad score is a wasted minute of my attention. Everything that crosses the boundary is done in my name and cannot be taken back. An agent with keys is a different thing from an assistant that answers questions, and the difference is exactly where that boundary sits and how well it is guarded.

Six rules that make the boundary real

A principle is only worth what the mechanisms behind it enforce, so here are the six that turn the line into a system. They are the constitution's articles, and each carries a test for what would count as a violation, because a rule without a violation test is a hope.

Approval binds to the exact payload. An approval is a record tied to the final wording and the final recipient. If either changes materially, the approval is void and the message goes back in the queue. This closes the most common hole in "human in the loop" designs, where a person approves a summary and the agent sends something else.

Approvals are single-use and time-bounded. One approval sends one thing once, and it expires. There is no standing permission to "send follow-ups", because a standing permission is an agent with keys and no supervision.

Budgets are enforced before dispatch, not discovered after. Every model call records its cost, and the system checks the owner's budget, the workflow's limit and the concurrency ceiling before it makes the call. The model provider's own spending cap is a backstop, not the control. An unattended workflow that can spend without a ceiling, a loop bound or a recorded cost is, by the constitution's own words, a violation. I wrote last week that "what can it spend" is the question most companies cannot answer about their agents; this is what an answer looks like.

Drafts must be evidenced. An outreach message is grounded in the owner's profile, projects and stated evidence, and a claim the system cannot support is flagged or blocked before the draft reaches the approval queue. The agent is not permitted to be plausible; it has to be right about me.

Reputation is protected structurally. Suppression lists, send-rate limits and source-policy compliance are in the system, not in the prompt. An agent that can be talked into emailing five hundred people is not saved by an instruction to be sensible.

Every decision is auditable. Which sources were watched, what trail was followed, why a candidate scored as it did, what was drafted, who approved it and when. An owner can disagree with the system, and should, and can only do that if the reasoning is on the record.

Why this is harder than it sounds

The temptation in agent design is always to move the boundary outward, because every step the human takes is friction and friction feels like a product failure. Let it send the obviously safe ones. Let it book the call. Let it apply, it is only a form. Each step is reasonable on its own, and the sum of them is a system that acts in your name without you, which is precisely the thing nobody wants until the day it happens. Autonomy is earned, and the way it is earned is by a long record of approvals that the owner never needed to change. Until that record exists, the boundary stays where it is.

The other temptation is to put the safety in the prompt. "Never send without approval" as an instruction to the model is worth roughly nothing, because a model follows instructions probabilistically and an attacker, or an ambiguous web page, can supply competing ones. The approval record, the budget check, the suppression list and the audit log are code and database constraints. They hold whether the model is having a good day or not. That is the difference between a hobby system and a professional one, and it is why the constitution exists as a document: so that when a later version of me, or a coding agent working for me, proposes a shortcut, there is something written down that says no.

What this has to do with your company

Very little of the above is specific to business development. Swap "outreach message" for "purchase order", "customer reply", "firmware release" or "journal entry" and the rules are the same. If your company is deploying an agent that can do anything outside its own system, the questions to ask are the six above, and the answer to each should be a mechanism you could point at, not a sentence in a prompt. Where is the boundary? What binds an approval to what actually happens? What stops it spending? What stops it inventing? What stops it flooding? What is on the record?

I will write about how VenturePilot behaves in practice once it has run for a while; a design that has not met real sources yet is a design, and the essay that matters is the one after the first month. For now the point is the line, and the fact that it can be drawn before a single lead is found.

Three things worth taking seriously

For anyone building an agent that acts for people: write the constitution first, with a violation test for every rule, and make the tests automated. Then build. The document is what stops the boundary drifting.

For leadership teams buying one: ask the vendor to show you the approval record for one external action, the budget check that runs before a model call, and the audit trail for one decision. If any of the three is "the model is instructed to", keep looking.

For independent professionals: the pipeline problem is real and an agent can help with it, but only one that never speaks in your name without you. Your reputation is the asset; the tool must be built so that it cannot spend it.

Which of your systems could contact a customer today without a person approving the exact words?

If you are working out where the boundary should sit for your own agents, that is a conversation I have often; the workflows-before-agents piece is the place to start reading.