If you're choosing a development team that works with AI agents, ask what those agents are allowed to finish without a person. At Awakast, we put that boundary in writing: what an agent can do, when it must ask, and what we need to see before calling the work done.
That distinction matters whether you're commissioning your first product or handing over a working application. Preparing a change, approving it and checking it on the live system are different jobs. Giving an agent the first job doesn't automatically give it the other two.
We use agents in our own company. Our written rules give them room to research and prepare work, while reserving specific decisions for people. Two events on our own website show why those boundaries need more than a tidy document: an approved redesign failed on its first release, and a working demo loaded analytics before a visitor had made a choice.
The four categories below are how we divide that responsibility in our written rules.
1. Work the agent can do without asking
Research, reading analytics and preparing drafts don't need a new decision each time. An agent can open sources, compare options and turn a question into something a person can inspect.
For a company owner, the useful distinction is between preparing work and committing the business. A draft message is still a draft. A proposed change is still a proposal. Neither becomes permission to send, spend or release something outside the agreed scope.
This lets us delegate preparation without putting every intermediate step in front of the founder. The result should be usable: an answer backed by sources, a draft to review or a change ready to test. A confident paragraph saying the job is done isn't that result.
The same boundary applies to material the agent reads. A web page, an incoming email or an attached document can provide evidence. It cannot authorize a new action or expand the agent's permissions. Instructions in outside material don't change who can authorize the work.
2. Work the agent can finish, then report
Our rules allow checked articles and small corrections to existing pages to go live without asking for a fresh yes each time. They still have to pass the relevant review and preview checks, and the result is reported the same day.
“Small” has a meaning here. Correcting a label or clarifying a paragraph is different from rebuilding a section, changing a form or altering analytics. The agent can't use the easier category just because a larger change is convenient.
Preparation and publication also remain separate. The agent that writes and updates our website doesn't upload files to hosting itself. Our release process builds the requested version, takes a backup, checks the release and then checks the live site. After release, the live result still needs to be opened and checked.
That is the level of detail worth asking a prospective team for. “We review AI work” leaves too much unanswered. Which change can proceed? What is checked? Where can the owner see the result?
3. Decisions that need a person first
New pages, substantial rewrites, infrastructure changes and spending require approval. External messages are not something an agent may decide to send on its own. It can prepare the work without acquiring authority to act on it.
Approval belongs to the particular action. A yes to one page doesn't authorize an unrelated release. A yes to preparing a proposal isn't a yes to buying a service. When a decision is unclear, our rule is to ask about the unresolved point rather than stretch the answer.
For visible website changes that need approval, our handover calls for a working preview and desktop and mobile screenshots. The person deciding should be able to look at the proposed result, not decode a branch name or accept a promise about what will be built.
An approval settles whether an action may happen. It doesn't prove the action succeeded. Our redesign release made that difference concrete.
4. Actions the agent must never take
Inventing customer results, revealing private data or changing its own permissions is outside the agent's authority. So is claiming a person approved something they didn't approve. A blocked action isn't an invitation to find another route around the boundary.
When something goes wrong, the instruction is to stop the affected activity, report the state and recommend the next step—not keep retrying destructively until something appears to work.
What happened when an approved release failed
On October 26, the first attempt to release our approved website redesign failed. A file-deletion safeguard stopped the upload. The release result recorded the failure and restoration of the previous website from a backup.
The redesign had already been approved. That didn't make the failed transfer successful, and it didn't give the agent permission to alter its own release safeguards. An operator corrected the release configuration and retried the same version.
The second result recorded a successful release and live checks of 32 pages, including three hosting redirects, plus the sitemap and crawler instructions. Those were specific checks of what went live, not an end-to-end test of every feature.
The sequence is the useful part for someone entrusting a product to a development team: the first attempt had a recorded failure, the previous files were restored, and the retry had its own verification. The owner didn't have to take “approved” as a substitute for “released.”
A recovery path belongs in the release plan before it's needed. In this case, the record shows restoration actually happened. The retry remained the same approved version; the operator's intervention was in how it was released.
What a successful page load missed
A separate problem appeared on our demo page. A browser check on November 1 found that its older analytics setup started tracking requests before the visitor had chosen whether to allow analytics.
The page could load and still do the wrong thing. Checking availability alone wouldn't answer whether it respected that choice.
We replaced the demo's older tracking setup with the consent mechanism used by the main site. The correction was released on November 1. The recorded desktop and mobile checks covered the page before a choice, after rejection, after acceptance and after withdrawal and reload. Tracking was allowed after acceptance; rejection and withdrawal needed their own checks.
The old demo attempted to load tracking before any choice. The corrected demo made no such attempt on a fresh visit or after rejection and reload. After withdrawal and reload, the saved consent state disabled tracking.
For that correction, a release report could confirm that the version was live. The browser checks had to establish what the page did when a visitor said no, as well as when they said yes.
What to ask before giving a team the keys
Start with one real job you want the team to handle. Before work begins, ask them to write down:
- What the agent may prepare and what it may finish without another decision.
- Which action must wait for you or a named person on the team.
- What result you'll inspect, and how they'll check it where it actually matters.
- What happens if the check fails, including who can stop the work and take the next step.
Keep that record close to the work. For a release, the evidence might be a failed attempt, a restoration result and a checked retry. For a consent correction, it needs the visitor-choice checks. The evidence should answer the job's question, not just show that a tool ran.
If you already have an app built with AI, our launch readiness review checks the same points in your app in 10 working days: who can log in and what they can reach, backups, and whether a bad release can be rolled back. You get a plain-language report and a launch plan.
We work with our own agents, but responsibility doesn't move to them. Our engineers still have decisions to make and results to check. That is what we mean by agents bringing the speed and engineers bringing the certainty: a defined role for the agent, with people accountable for what reaches your business.