Accountable human, executing AI: the contract that organizes the squad

“AI executes; people lead, decide and generate results” is a good direction — as long as it doesn’t become a slogan that leaves all responsibilities implicit.

Executing does not mean receiving unlimited authority. Leading does not mean approving every click. And being accountable doesn't mean manually reviewing everything a machine has produced. A human–AI squad works when intent, authority, verification and decision are explicitly distributed.

The core contract is simple:

The person is responsible for the intention, the limits and the irreversible decision. AI is given scope to execute. Controls check properties. Evidence makes the outcome attributable.

Accountability cannot be outsourced

An agent can research, write, program, test, organize, and operate. It can also propose a better plan than the first human idea. None of this automatically shifts responsibility for the effect of the decision.

Responsibility requires someone capable of responding:

• why this problem was chosen;
• what risk was accepted;
• which people may be affected;
• what evidence was sufficient;
• why the result was published, shipped or put into production;
• what will be done if the decision is wrong.

This person does not need to perform all the tasks. It needs to retain authority over the purpose and limits that the system cannot change alone.

The operating contract in six clauses

1. Intention: the result that matters

Every session starts with an outcome, not an infinite list of actions. The human declares the problem, the business context, the acceptance criteria and what is out of scope. AI can decompose and question; You cannot silently exchange the objective for another that is easier to demonstrate.

2. Authority: what can change

Each role is assigned minimum capabilities. Researching does not imply writing. Writing code does not imply publishing. Publishing does not imply accessing customer data. Authority grows with risk, reversibility, and evidence — not with subjective confidence in the model.

A durable architecture separates session history, orchestration policy, and execution environment. This allows you to replace model, sandbox, or channel without making any of them the security boundary. [HARNESS31-C2]

3. Stop: when to return control

The agent needs stop conditions: budget exceeded, material uncertainty, conflicting source, external action, sensitive data, destructive change or repeated failure. Asking for confirmation is not failure; It is correct behavior when the authority received has ended.

4. Verification: who observes the executor

The same agent can perform a useful self-assessment, but self-assessment is not independence. Tests, linters, scanners, contracts, and specialist reviewers observe different properties. For high risk, the verifier needs an identity, tool, or criterion separate from the executor.

5. Evidence: what allows you to defend delivery

A result needs to carry its trail: source, version, commit, checks, exceptions, approver and validity. Evidence is not just for subsequent auditing. It reduces ambiguity during work and makes corrections findable.

6. Decision: who has an effect in the world

The last clause defines the gate. Low-risk, reversible changes can move forward automatically when contracts pass. Actions with legal, financial, reputational, security or personal effects require nominal human authority.

Papers by capacity, not by model

“Architect uses X” and “Backend uses Y” get old when models change. A more stable roster describes capabilities:

• Architect decides boundaries and trade-offs;
• Security models threats and blocks critical risk;
• Backend implements service contracts;
• Frontend transforms contract into accessible experience;
• QA defines and executes the assurance network;
• DevOps automates delivery and rollback;
• Tech Writer preserves decision and operation;
• PO orders issues by value and risk.

The orchestrator chooses the appropriate model, tool, and isolation for the task. The paper remains the contract; the model is a replaceable implementation.

The sources evaluated by FORGE also show why shared capabilities need to be scoped and managed, while portal, web, chat and other channels remain replaceable surfaces. This inspires architecture; does not replace deny-by-default, revocation, and actual authorization testing. [HARNESS31-C4]

A real flow: publish an article

This collection itself offers an example.

The human chooses the thesis, assumes authorship and authorizes publication. AI researches, cross-references sources, structures, writes, links claims, generates projections and performs QA. The contract prevents a draft from being included in a sitemap or feed. Scanners observe secrets and personal data. The digest holds approval to the exact text. The agenda releases the article only on the approved date.

No single layer guarantees quality. Together, they make it clear:

• who is an author and who is a publisher;
• where there was AI assistance;
• which review mode was used;
• which sources support each claim;
• when the content was published;
• how a fix will appear without erasing the history.

This design allows high automatic execution without fictitious authorship and without accidental publication.

Humans should not become a bottleneck

A bad interpretation of human-in-the-loop puts a person in each transition. The result is a queue of superficial approvals: the system asks “ok” so many times that the human stops evaluating it.

The gate must be proportional to the consequence:

• low risk and reversible: automatic execution with contract and observability;
• medium risk: sampling, review by exception and quantitative limits;
• high risk or external: nominal human approval before effect;
• destructive, sensitive or legal: double checking, reinforced evidence and proven rollback.

The goal is to focus human judgment where it changes the decision. Everything else must be engine-verifiable.

Companies amplify the system they already have

DORA 2025 describes AI as amplifying existing strengths and weaknesses, associating the greatest returns with the organizational system, and not just the tools. The result is focused on software development and should not be converted into universal law, but it offers a useful warning: automation does not fix unclear authority, missing criteria, or slow feedback. [CAREER-A18-C5]

In a company with clear intent, good contracts and learning, AI expands the flow and access to knowledge. In a company that measures volume and hides flaws, it expands production without acceptance, review and debt.

The new leadership job

Leading a human–AI squad involves less manual distribution of tasks and more system design:

• formulate problems and priorities;
• make criteria observable;
• define boundaries of autonomy;
• create climbing paths;
• invest in evals and quality data;
• observe cost per accepted outcome;
• transform incidents into durable mechanisms;
• preserve training and human context.

This applies to formal leadership and individual professionals. One person can lead a technical, editorial or commercial decision without managing a team.

Training: learn to drive and check

When AI takes over entry-level tasks, young professionals run two risks: outsourcing fundamentals too soon or running out of incremental tasks to learn. The squad contract needs to use execution as training material.

Those just starting out can:

1. write the specification before asking for implementation;
2. declare hypotheses and points of uncertainty;
3. compare generated alternatives;
4. run tests and explain why they are sufficient;
5. review the diff and sources, not just the final answer;
6. record failure, correction and rule learned;
7. assume progressive autonomy in areas of greater consequence.

Thus, AI reduces repetition without eliminating the construction of judgment.

Metrics that reveal the real contract

The organizational chart tells you who should decide. Metrics show who actually carries the work.

Please note:

• time until outcome accepted;
• percentage of deliveries approved without material rework;
• human review burden by type of risk;
• number of useful escalations versus automatic commits;
• faults detected before and after the external effect;
• total cost per result, including review and correction;
• autonomy achieved by people and agents within defined scopes;
• decisions without a nominal owner;
• expired exceptions still operating.

If the AI produces more and the review grows at the same rate, the squad just moved the queue. If approvals fall but incidents rise, autonomy has been confused with lack of control.

Checklist before delegating

Before handing off a task to an agent, respond:

1. What outcome and what limit?
2. What capability is needed — reading, writing, executing or publishing?
3. What data and systems are prohibited?
4. What does the agent do when he doesn't know?
5. Which control verifies the result?
6. What evidence needs to survive?
7. Who has the final decision?
8. How to reverse or withdraw?
9. What should become learning afterwards?

Without these answers, “autonomy” is just undocumented authority.

Conclusion

A human–AI squad is not a group of models simulating roles. It is a system of responsibilities: people define intention and respond to consequences; agents execute in delimited scopes; controls check; evidence connects work and decision.

This enables something more ambitious than blind automation and more efficient than human approval at every step.

AI amplifies execution. The human retains purpose and accountability. The contract between the two is what transforms speed into results.

Previous reading: The model is not the system.