An AI agent should reach a production system only through a narrow, auditable path built for the task it must complete. Giving it broad admin-console access may finish today’s workflow, but it also turns one helpful action into an uncontrolled production risk.
At 4:47 on a Friday afternoon, Malik had one hand on a paper cup of cold coffee and the other on a laptop balanced against the edge of a desk in Accra. He and Priya were building an assistant for a small operations team. It could read an incoming request, pull the relevant account details, draft the next action, and prepare the update.
Then it stopped.
The last step required changing a record in the production admin console, which they had deliberately kept off public cloud. The console carried customer data and a few controls that could affect live work. Their assistant could explain exactly what needed to happen. It could not finish.
A customer was waiting for the update before close of business. If Malik gave the agent a shared administrator login, the request might be resolved in minutes. If the agent made the wrong change, or followed a prompt that had been shaped to make it overreach, they could create a problem their two-person team would spend the weekend untangling. The workflow was close enough to work that stopping felt absurd. The remaining step was also the one they had protected most carefully.
The blocked step revealed the real product boundary
The easy response is to treat this as a permissions problem: create an account, add a token, let the agent through.
That response skips the harder question. What action does the product actually need the agent to take?
Malik and Priya did not need an assistant that could browse every customer record, change settings, invite users, or run every administrative operation available in the console. They needed one bounded action: apply a reviewed update to a specified record after the assistant had gathered the right context.
That distinction matters because AI agents are good at crossing steps that humans usually connect informally. A person can see an email, open an internal tool, remember an exception, and make a change. An agent needs each handoff defined. When the handoff reaches a protected system, vague permissions become part of the product design.
The agent asking for the admin console was useful information. It showed that their demo had reached a real workflow boundary. It did not prove that the console should become an agent tool.
This is related to the question behind AI demos that hide the work that erases their margin. A workflow can look complete while the expensive, risky, or manual step sits just outside the frame. In this case, the hidden work was a person with production access.
They replaced console access with one constrained action
They did not finish the Friday request by opening the full console to the model.
Instead, they mapped the exact action the assistant needed to perform and put a small internal service in front of it. The agent could submit a proposed change with the record identifier, the requested update, and the source context it used. The internal service checked the request against allowed fields and values, recorded the action, and rejected anything outside that narrow scope.
For the first version, Malik still approved each proposed change. The agent prepared the work. He saw the before-and-after state in one screen, then allowed the internal service to apply it.
That felt slower than giving the model a login. It was slower, for a few hours.
But it answered questions that a shared admin account would have hidden:
- Which changes are safe to automate?
- What information must the agent provide before a change can happen?
- Which exceptions need a human decision?
- How will they investigate a mistake after the fact?
The answer to the first question was smaller than they expected. A few actions covered the useful part of the workflow. Everything else stayed behind the console.
A system running inside your own network can make this easier when it needs to work beside internal services, source control, or a build setup that does not belong on a public cloud. Location alone does not solve the permission problem, though. An agent running close to production still needs a clear boundary around what it may do.
Approval is a product phase, not an embarrassment
Teams sometimes treat approval as evidence that their AI product is unfinished. That can lead them to automate the last action before they understand the consequences of getting it wrong.
For Malik and Priya, approval was how they learned where the workflow broke. On Monday morning, Priya noticed that the agent repeatedly proposed a change when an account was missing one piece of context. The correct response was not an update. It was a request for clarification.
If they had granted broad console access on Friday, that pattern might have become a string of incorrect production changes. With review in place, it became a design requirement: the assistant had to identify uncertainty and stop.
This is where a two-person team can make a better decision than a larger company with more layers. You can watch the assistant work closely enough to see its bad assumptions. You can turn those assumptions into rules before they become customer-facing damage.
The right level of autonomy is often different across steps in the same workflow. Let the agent read, summarize, classify, draft, and prepare. Give it the ability to make a live change only when the action is narrow, reversible where possible, and easy to inspect.
Build the permission model before the polished demo
By the following week, Malik’s cold coffee was gone and the workflow had changed shape. The assistant still could not enter the admin console. It no longer needed to.
It prepared a specific request for a specific internal action. Priya could approve it from the same review view where she checked the context. When an unusual case appeared, the system left it for a person instead of guessing.
That is a more honest demo. It shows where the agent is useful, where production controls begin, and what the team still has to learn.
For founders building on limited runway, this can also prevent a costly detour. A broad integration feels like progress because it removes a visible block. A narrow internal action forces a useful choice: define the one outcome worth automating first. The rest of the console can wait.
Comments
No comments yet.