The wrong measure of an AI software team is how long it can operate without speaking to a human.
Silence can look like autonomy while hiding a much simpler failure: the system did not recognise that it was making a decision it had no authority to make.
Real software projects are full of judgement:
- a requirement is incomplete;
- two priorities conflict;
- a security shortcut would make delivery faster;
- an implementation keeps failing;
- a change affects cost;
- the original product idea no longer matches what users need.
A useful team should not escalate every small choice. That would turn the user into a full-time approver.
It should not silently decide everything either.
The real design question is:
Which decisions can the team make, which must it record, and which must come back to a human?
Maximum autonomy is not the goal
Suppose a frontend developer role needs to choose between two internal names for a component. The choice is local, reversible and has no business impact. Asking the founder would be wasteful.
Now suppose the team discovers that the requested feature requires collecting customer email addresses, even though the original product was described as anonymous. That changes privacy, storage, user experience and perhaps the commercial proposition.
Treating those decisions as equivalent is not autonomy. It is a missing authority model.
Good orchestration gives different classes of decision different paths.
A four-level decision model
One practical model is to separate decisions into four levels.
Level 1 — Execute within agreed constraints
The team can proceed without interrupting the user when the decision is:
- low risk;
- local to one implementation area;
- easily reversible;
- already covered by an agreed standard;
- unlikely to change cost, security, data handling or product behaviour.
Examples:
- naming a private helper function;
- choosing a clear internal folder structure;
- adding a test for a documented edge case;
- using the existing design-system component;
- fixing a lint or formatting issue.
These decisions do not need a meeting. They need competent execution.
Level 2 — Decide, record and continue
Some choices are still safe for the team to make, but the rest of the project may depend on them.
Examples:
- selecting one of two equivalent library patterns already allowed by the architecture;
- defining a pagination default within an approved range;
- choosing a reversible caching strategy;
- making a small interface assumption that does not affect stored data;
- refining acceptance criteria without changing the intended product outcome.
The team should record:
- what it decided;
- why;
- which alternatives it considered;
- what would invalidate the decision.
That record becomes part of shared project context.
The user does not need to approve every choice, but the decision should not vanish into one agent's chat history.
Level 3 — Recommend and ask
A human decision is appropriate when the choice changes the meaning, risk or economics of the product.
Examples:
- anonymous use versus account creation;
- storing customer contact information;
- a major architecture trade-off;
- cutting a requirement to protect the delivery date;
- choosing between materially different ongoing costs;
- changing the audience or user journey;
- accepting a known limitation;
- expanding the project beyond the approved brief.
The team should not return with a vague question such as:
What do you want to do?
It should produce a compact decision packet:
Decision:
Should users create an account before submitting feedback?
Why this needs you:
It changes conversion friction, identity handling, privacy and the data model.
Option A:
Anonymous submission.
Lower friction and less personal data, but no direct follow-up.
Option B:
Account or verified email.
Enables follow-up and history, but adds authentication and data obligations.
Recommendation:
Use anonymous submission for the first release and keep follow-up out of scope.
Impact of no decision:
Backend data model and public form cannot be finalised.
The purpose of orchestration is not merely to detect a question. It is to make the question cheap for the human to answer.
Level 4 — Stop and escalate
Some conditions should pause the affected work.
Examples:
- a request for secrets, production credentials or unrestricted system access;
- a decision that may expose personal or confidential data;
- an irreversible external action;
- an unapproved payment, purchase or deployment;
- a legal or compliance conclusion outside the approved policy;
- spend approaching an enforced limit;
- repeated implementation failure with no credible recovery path;
- requirements that directly contradict each other;
- evidence that the requested outcome may be unsafe or impossible under the stated constraints.
Continuing in these situations does not demonstrate initiative. It consumes money and increases risk while pretending the decision has already been made.
A stop should be specific. It should identify the blocked work, preserve completed outputs and explain what is required to resume.
Seven signals that should trigger human judgement
The four levels become easier to apply when the team watches for clear signals.
1. The requirement changes the product
If resolving an ambiguity alters who the user is, what data is collected, what the product promises or how money moves, it is not an implementation detail.
2. Two valid goals conflict
"Ship quickly", "support every edge case", "minimise cost" and "use the most robust architecture" cannot always be maximised together.
The system can explain the trade-off. The owner must decide which goal dominates.
3. The action is difficult to reverse
Creating a local file and sending a customer email are not the same class of action.
External publication, deployment, payment, deletion and production-data changes deserve explicit authority.
4. Security, privacy or compliance is affected
The team may identify risks and recommend controls. It should not invent the organisation's risk appetite or provide a legal conclusion as if it were a product decision.
5. Cost moves outside the agreed boundary
The user may approve an overall ceiling, a session budget or a specific expensive step.
Once the work approaches that boundary, the correct behaviour is to warn, explain and stop according to the agreed rule — not to keep working because the next attempt might succeed.
6. The same work repeatedly fails
One failed implementation is normal.
Repeated failure without a changed hypothesis is a loop.
At that point the team should surface:
- what was attempted;
- why each attempt failed;
- what evidence changed;
- what alternative it recommends;
- whether the problem requires a different specialist or a human decision.
7. The original context is no longer reliable
Projects change.
If a later instruction contradicts an earlier decision, the team should not simply obey whichever message is newest. It should identify the conflict and determine whether the previous decision has been superseded.
Shared memory is useful only if the system can recognise when it no longer agrees with itself.
Human judgement does not mean human micromanagement
A badly designed approval system asks too many questions.
A useful one protects human attention.
The team should handle routine execution and surface only decisions that have enough impact, uncertainty or irreversibility to justify interruption.
That means an escalation should arrive with:
- the relevant context;
- the exact decision;
- realistic options;
- a recommendation;
- known consequences;
- the effect of waiting;
- the work that can continue in parallel.
The human remains accountable without becoming the message bus between every role.
How this shapes Brewyard
Brewyard is being designed around visible authority rather than invisible autonomy.
Inside a workspace:
- roles receive defined responsibilities;
- work moves through explicit delegation;
- assumptions and decisions remain inspectable;
- handovers carry shared project context;
- review can return work to the responsible role;
- spend boundaries are visible and enforceable;
- consequential decisions can come back to the user.
That does not guarantee that the team will always escalate at the correct moment. Determining those boundaries reliably is one of the hardest parts of the product, and one of the main reasons the private beta needs real projects rather than polished demonstrations.
The most valuable failures are not always broken builds. They are cases where the system continued when it should have asked, or interrupted when it should have known enough to proceed.
A simple rule
An AI software team can decide when the choice is local, reversible and inside an approved boundary.
It should record when other work may depend on the choice.
It should ask when the decision changes product intent, risk or cost.
It should stop when the action is unsafe, irreversible or outside its authority.
A good team is not the one that never asks a question.
It is the one that knows which questions are worth your attention.