Give AI the intent, the tools, and the prerogative to execute. Expect a finished result. I use persistent Claude specialists to turn a clear brief into work I can inspect, without directing every step.
One intent, many minds
I want my AI workers to execute with impunity, at their own prerogative.
The word choice is deliberate. I served as Data Chief with the Marine Corps' 2nd Reconnaissance Battalion. Later, I led cloud automation at Transact Campus and built delivery systems through UDX. Across those environments, the same problem keeps appearing: capable people and capable machinery waiting for someone to authorize the next obvious step.
If I have to prescribe every action, resolve every routine choice, and approve every attempt, I am still doing the work. I have added a conversational interface to my own workload.
What I want is to communicate intent and have execution continue while my attention is elsewhere.
Intent carries further than instructions
The useful idea I bring from that background is commander's intent: make the purpose and desired end state clear enough that execution can adapt when the original plan stops fitting reality.
For an AI worker, that means understanding what I am trying to accomplish, having access to the material it needs, and knowing what a completed result must satisfy. It can choose the implementation, inspect what happened, change its approach, and keep going.
Prerogative is the latitude to make those decisions. If a reference path has moved, find it. If the first render is wrong, fix it. If a tool fails, investigate another supported route. Those are execution decisions. They should not all come back to me disguised as questions.
The authority to pursue the assignment comes from me. The choice of how to carry it out belongs with the worker, close to the actual work.
Impunity is something you build
In my Deploying With Impunity writing, the premise is that operational freedom comes from structure: explicit requirements, validation, and machinery that can keep moving when conditions change.
I apply that thinking to AI. I want a worker to have enough room to attempt, inspect, revise, and finish without making each iteration a ceremony. A failed first attempt inside a recoverable workspace should be cheap. Discovering a better approach should be expected.
That freedom has to exist in the environment. Put the work under version control. Give the worker the relevant tools and a clear area of responsibility. Make results visible. Build checks that can tell it when the output is wrong. Keep consequential access tied to the actual assignment.
A permission flag cannot create those conditions by itself. It can remove a prompt. The workspace, access model, and verification process determine what the worker can actually do and whether the result deserves to ship.
I retain responsibility for the mission I delegate and the access I provide. The worker's freedom to act is how execution happens; it does not transfer my responsibility to the model.
A small test of the whole idea
I asked an assistant to learn how my Claude workers operate. Then I gave it a deliberately underspecified test: make me an SVG through a worker that I would like.
The assistant found svg-forge, checked that it was available, and sent it a brief through the worker's REST API. It also discovered that the worker's current workspace differed from the paths in older documentation and supplied the correct reference location.
The worker read its saved style guide and existing illustrations. It already had a record of my preferences: square corners, thin linework, restrained color, generous whitespace, and no decorative scribbles. It used those references to create the image above.
Then it rendered the SVG and looked at it. It corrected a caption grouping issue and replaced a central glyph that looked too much like a menu. It rendered again and returned the editable vector and a PNG preview. The commissioning assistant inspected the finished image too.
My verdict was “not bad.”
I had not specified the coordinates, the glyphs, or the arrangement. I had specified the outcome: make something I would like, using the specialist. The system carried the assignment through the decisions necessary to produce an inspectable result.
That is the behavior I am testing for. Can it take the mission and finish?
Give specialists something to remember
Each Claude worker in this setup runs as an independent Claude Code session in a Docker container, with a mounted workspace and persistent session files. A small HTTP interface lets another assistant or script give it work and retrieve the result.
The valuable part of svg-forge is its accumulated reference material. It has a style guide containing examples, palettes, conventions, and corrections from previous reviews. A later assistant can commission the specialist without relearning every preference itself.
I use written knowledge for this deliberately. Session files preserve history, but a restarted process is not a guarantee that the right conversation resumes. A maintained guide gives the next session something concrete to consult.
A useful specialist should leave two things behind: the artifact it was assigned to produce, and any reusable knowledge that makes the next assignment better. Repeated corrections should become part of how it works.
The interface can stay small
The caller checks the worker, submits a brief, and collects the result. Here is the basic interaction with an illustrative worker on local port 3120:
curl -sS http://127.0.0.1:3120/status
curl -sS --max-time 150 \
-X POST http://127.0.0.1:3120/ask \
-H 'Content-Type: application/json' \
--data-binary @brief.json
The JSON file carries the assignment and how long the API should wait:
{
"prompt": "Read your style guide. Create the requested SVG in /workspace/output/. Choose the composition. Render and inspect it, fix what is wrong, and return the SVG and PNG paths.",
"timeout": 120
}
/ask waits for a response. /status reports idle or busy. /read and /transcript expose recent output. /send returns immediately so the caller can do other work before collecting the result.
This implementation drives a live terminal session; it does not provide a durable job queue. I keep one outstanding assignment per worker. If a request times out, I check what the worker is doing before sending anything again. A caller ceasing to wait does not mean Claude stopped working.
The REST ports are bound to host loopback, and this API has no authentication layer of its own. It belongs on the local machine. Shared writable workspaces also require explicit ownership so two specialists do not overwrite each other's work.
Those are concrete operating conditions. Once they are established, the worker should be able to get on with the assignment.
Bring back the result
I expect initiative within the mission: research the unfamiliar part, use the available tools, recover from an ordinary failure, and verify the output. Escalate a decision that changes the mission or requires authority I have not given. Routine implementation choices are the worker's to make.
The final report should make the result easy to judge. Show the render. Point to the changed files. Supply the sources. Verify the published URL. Say what remains unresolved when something genuinely could not be completed.
That is the arrangement I want: I give the intent, the worker exercises its prerogative, and the evidence comes back with the work.
Execute with impunity. Bring me the result.