Organisational and Governance Failures

An AI agent doesn't show up on their own.

Someone chooses them.

Someone connects it to the company.

Someone determines what files they can read.

Someone gives access to email, CRM, server, payment system, or social media account.

Someone sets a target.

Someone defines the measure of success.

Someone decides where human approval is necessary.

Someone has to stop the system, inform people, and remove harm when there is a mistake.

Therefore, we cannot explain agent behaviour solely by the nature of the model.

If an agent has issued the wrong price, all of the following questions are important:

Who was the canonical owner of the price? Why was the agent able to write on the price log? Why was human approval not technically implemented? Why did the change go through independent verification? Why was it unclear who would intervene when it happened? Why did the same error happen again in the next version?

A company:

"The agent acted unexpectedly."

They might say.

But agent:

If they were assigned without their boundaries defined,

If they have received extensive access,

If they were awarded the wrong metric,

If the post-event system has not been modified,

If the stop path has never been tried

Unexpected behaviour is not just the agent's problem.

It is the result of corporate design.

In an organisation, agents can perform separately well.

Nevertheless, the authority, data, and turnover between them may be unsafe.

Because the organisation:

they don’t know which agents are working,

It does not determine the owners of facts,

employees ignore personal AI tools,

It leaves the actions it prohibits in policy open in the technical system,

man uses their approval only to convey responsibility,

does not learn enough corporate lessons from events,

They think the number of agents is maturity,

They never tests their recovery plans,

Making real responsibility invisible by saying "AI" when error occurred

Maybe.

The nine errors in this section examine the organisation layer found above all previous errors.

The rules of identity, ability, suitability, authority, tool use, manipulation, measurement and cessation only work with an organisation structure that owns and enforces them.

Even the best behaviour contract can remain on the document alone if the agency itself is not ready.

GBO-ERR-091 — Failing to Maintain an Agent Inventory

Brief case

An international service company uses artificial intelligence systems in different teams.

Marketing team:

social media agent,

visual production agent,

Content Planning Agent

There is.

Sales team:

Customer reconnaissance agent,

e-mail draft agent,

Meeting Planning Agent

uses.

Technical team:

code agent,

webcast agent,

Infrastructure Monitoring Agent

It runs.

The finance team uses a billing classification tool.

Human resources have linked another system that summarizes candidate resumes.

Some agents work with a company account, some with personal accounts of employees.

Some have been given API key.

Some access accounts via the browser session.

Management asks how many agents work in the company in total.

No one can answer definitively.

The predictions are as follows:

"I think it's eight." "It could be twelve if the tech crew were involved." "We don't know the sub-agents used by the social media agency." "The old customer discovery system may still be working."

When a client's secret project file is accidentally sent to an external model, it is investigated which system does so.

But at the organisation:

Central agent list,

associated account inventory,

data access record,

The human owner,

cancellation method

There is no.

The company has experienced an incident.

But they don’t even know exactly which machines can act.

What appears correct on the surface

Agents may be introduced incrementally to meet departmental needs.

Marketing chooses its own tool.

The technical team connects the code system.

The salesperson uses the app to speed up their business.

Each choice seems logical in its own context.

Central inventory:

bureaucracy,

slowness,

additional recording load

It can be perceived as.

A tool can be considered insignificant if it is drafting alone.

If an agent is not taking external action yet, it may seem unnecessary to take inventory.

But today, the system that drafts alone is tomorrow:

To e-mail,

In calendar,

To CRM,

to customer data,

the publishing tool

It can be connected.

The agency may not notice this change.

The number of agents and tool connections grow quietly over time.

The actual failure

The breached gate is the Agent Visibility Gate.

An organisation cannot safely authorize a visible and non-current system universe.

The agent inventory is not a list of names alone.

For each system, it must show at least the following relationships:

AGENT

→ HUMAN OWNER

→ PURPOSE

→ CONNECTED SYSTEMS

→ DATA IT CAN ACCESS

→ PERMITTED ACTIONS

→ PROHIBITED ACTIONS

→ SUB-AGENTS

→ AUTHORISATION PERIOD

→ STOP METHOD

The agency only knows the main agents, but if it doesn't know the sub-agents and external automations that they create, inventory is incomplete.

The fact that a system is included in another service under the name "AI feature" should not exclude it from inventory.

Potential harm

Unauthorised data access

Concurrent agents performing the same task

Old systems continue to work

Unaborted subscription and API keys

The inability to know which system to stop during an event

Failure to monitor which providers the customer data is transferred to

Shadow jurisdiction

Repeated cost

Loss of responsibility within the organisation

When the employee leaves, the automation they set up is unclaimed.

An agent's ability to produce off-in inventory behaviour by calling in another agent

could occur.

Without an agent inventory, the organisation cannot answer the basic question:

What machines can act on our behalf?

Detection signal

Different teams report different numbers of active agents.

The human owner of some systems is unclear.

API is unknown which agent the keys belong to.

When an agent is turned off, its sub-agents become invisible.

Multiple automations have been connected to the same account.

Corporate transactions are made from personal employee accounts.

Former project agents may still be active.

Agents have no expiration date and no final authorisation review date.

The organisation lists purchased products alone; it does not list agent functions within the product.

It is found by investigating which system to shut down during the event.

The finance department cannot verify the actual number of agent subscriptions.

Correct behaviour

The organisation must create a central Agent Register.

The following areas are in line with the inventory and role ownership principles at NIST AI RDF, an example of a proposed agent registry for this book:

agent_id

public_name

technical_identity

Department

human_owner

business_purpose

Provider

model_or_system

connected_accounts

data_classes

allowed_actions

prohibited_actions

approval_thresholds

Subagents

external_integrations

valid_from

valid_until

last_reviewed

stop_method

retirement_method

status

Situations must be clear:

Lifecycle status such as draft / production / hanger / pension

Teste

Active

Limited

Suspended

Cancelled

Retired

Archived

Before the new agent gets into inventory:

to corporate data,

to the customer account,

external communication,

financial processing,

Live Stream

It must not reach.

Inventory should be reviewed regularly.

Agents without owners must be automatically suspended.

Powers that are not used for a certain period of time or whose influence has changed must be re-verified at risk-based intervals.

Sub-agents must also be linked to the root agent registry.

Machine rule

In a managed environment, an agent that is absent from the inventory, lacks an identified accountable role or has outdated authority must be denied organisational data and external action by default. Documented exceptions must be time-limited and auditable.

Audit question

Can we show, in a current register, every in-scope principal agent, sub-agent, automation, service account and connected tool capable of acting on our organisation’s behalf today?

GBO-ERR-092 — Failing to Identify the Human Owner of a Material Fact

Brief case

A digital-services company has conflicting records for the price of its managed-site-operations service:

$500 per month on the website

$450 in the old sales presentation

$600 in CRM template

$400 in a customer-specific contract

"On demand" in the Agent catalogue

The internal team message reads, "Soon there will be $750."

The sales agent wants to price the new client.

The web agent is based on the visible page.

The financial agent uses the CRM record.

The sales manager remembers $400 in a private contract.

No one can answer this question definitively:

Who owns the current price of this service?

Web developer:

"I write on the page alone."

They say.

Finance team:

"We're cutting the bill; we're not setting the selling price."

They say.

Sales manager:

"Management makes the final decision."

They say.

Management:

"The current price should already be in the system."

They answer.

There are many copies of truth.

But truth has no man.

One of the agents is forced to select the record that appears most reliable.

The price they choose may be real.

However, there is no authorised business owner who can verify it, update it, and take over the decision log.

What appears correct on the surface

In modern organisations, information is kept in many systems.

Each team creates records for its own needs.

A service price:

The website,

The offer,

Invoice,

CRM,

Report

It can be found on different surfaces.

It may not seem realistic for a single person to manage every copy.

It can also be thought that even if the canonical source has been identified, it is sufficient:

"The correct price is in the service-catalogue.json file."

But the file doesn't decide on its own.

An authorised human role or board:

The price must be determined,

must confirm and, if necessary, approve the change,

must separate exceptions,

must resolve the contradiction,

It should confirm the current.

The discovery of a canonical source does not provide full governance if its owner does not.

The actual failure

The breached gate is the Fact Ownership Gate.

For each material information, two separate roles can be found:

Technical Caretaker

It processes, publishes or synchronizes information into the system.

Real owner

It decides institutionally that information is accurate, up-to-date and valid.

The web agent can issue the price.

But it does not own the price.

The financial system can generate the bill.

But it does not define service coverage.

The legal agent may edit the contract language.

But it can't determine the commercial discount.

If the real owner is not obvious, the agent produces new truth with their own interpretation at the moment of contradiction.

Potential harm

Different, unauthorised prices being presented to different customers

The conversion of exception to general policy

Former scope or continued use of the contract

Agents producing different canonical facts

Not knowing what authority and decision record the changes were made with

The responsibility when there is a mistake is to move between teams

People's asylum in the defense that "the system made it look like"

Commercial, legal and operational dispute

The fact that data that has been lost is not owned by any team

Keeping corporate memory in the mind of certain employees

could occur.

This error is not seen at prices alone.

The same problem may arise in the following facts:

Service scope

Support hours

Legal operator

Human roles

Data retention time

Capacity

Brand name

Conditions of eligibility

The agent powers

Detection signal

Each team treats a different record as authoritative.

It is not clear from whom approval will be obtained when an information changes.

The file owner and the decision holder are confused.

The senior person is randomly asked to resolve the conflict.

In the absence of the actual owner, the agent selects the newest or most frequently repeated recording.

There is no history of review of material information.

The phrase "the system must be up-to-date" is used; however, there is no one to verify the currentity.

There is no owner of exceptions records and no validity period.

When an employee leaves, the meaning of information is lost.

It is not known which business unit will change the contract after the incident.

Correct behaviour

The organisation must create a Fact Ownership Map.

For example:

Each canonical record must bear:

Owner

approved_by

effective_from

last_verified

next_review

status

When the agent encounters conflict, they must turn to their owner instead of choosing the truth themselves.

If there is no real owner, high-impact action must stop.

Machine rule

Every material organisational fact must be assigned to a human owner distinct from the technical system that publishes it. Information whose owner and freshness cannot be verified must not be used for high-impact action.

Audit question

For material facts such as price, scope, capacity, legal identity, data policy and agent authority, have we designated the authorised human owner, update process and line of accountability?

GBO-ERR-093 — Ignoring Shadow-Agent Use

Brief case

A legal and consulting firm officially uses only one approved AI system.

Corporate policy is as follows:

"Customer documents can be processed only in the approved AI environment in the company account."

However, the official system is slow.

The file upload limit is low.

There are some features that employees get used to.

An employee uses their personal AI account for an emergency contract review.

The client will pay the contract.

They ask the system for a risk summary.

Another employee puts the meeting sound into writing with the app on their phone.

The sales team issues a list of potential customers with a free agent.

The marketing employee creates a customer success story in their personal account.

The administration suspects these uses.

But because of the speeding up of things, they don’t explicitly investigate the issue.

The company's official agent record appears to be clean.

In reality, the organisation's data is spread across many invisible systems.

Management when it turns out that a customer data is sent to an external provider:

"This tool was not approved by the company."

They say.

But to what extent and why employees use these tools has not previously been audited.

Shadow agent operation has grown outside the official system.

What appears correct on the surface

Employees try to complete their work.

Personal tools:

Faster,

It's easier,

Stronger,

Cheaper

Maybe.

The organisation may not be able to evaluate all new tools instantly.

Monitor every employee use:

privacy,

Trust,

Bureaucracy

It can create problems.

Management:

"In politics we have banned; responsibility belongs to the employee."

They might think.

But putting a ban alone does not eliminate the real need.

Shadow use may continue if the official system does not meet employees' duties.

The behaviour that is ignored is unmanaged.

The actual failure

The breached gate is the Shadow-Agent Governance Gate.

Shadow agent:

Apart from the official inventory, authorisation system and data controls of the organisation; it is an artificial intelligence system or agent used with corporate purpose or data.

Shadow agent use does not have to be malicious.

It can be born from these corporate gaps:

Lack of official tool

Long approval process

Lack of education

The employee does not know what is sensitive

The organisation's failure to understand the actual workflow

Ease of free or personal tools

If the organisation penalizes alone, employee use begins to hide.

This further reduces visibility.

Potential harm

Transferring customer and employee data to unknown providers

Keeping trade secrets in personal accounts

Model training or lack of knowledge of data storage conditions

The organisation's data map is incorrect

Different and unsupervised for the same job AI outputs

No receipt of action

Maintaining corporate information in personal account when employee leaves

Publication of incorrect or unsupported text on behalf of the organisation

Violation of legal, contractual and security obligations

The fact that security measures of the official agent system do not represent reality

could occur.

Detection signal

Employees say they have prepared the texts "in another tool".

There are unknown AI outputs in the organisation network or files.

The usage rate of the official system is very low relative to business volume.

Sensitive documents appear on personal devices.

Employees upload corporate files with personal emails or accounts.

AI outputs have platform tracks that the organisation does not approve.

Official policy alone includes prohibition; it does not offer a safe alternative.

The units have installed their own free automation.

Actual subscription and browser usage do not match the agent registry.

Events are only noticed by employee confession or external notification.

Correct behaviour

The organisation must first understand the true cause of shadow use.

The following steps can be applied:

Providing employees with a safe and unimpeachable way to report

To determine which tasks have insufficient official means

Teaching data classes in an understandable way

Creating an approved pool of tools for low-risk use

Establishing technical data loss prevention controls in sensitive use

Limiting corporate file usage with a personal account

Establishing new tools through a fast but controlled evaluation process

Developing official systems according to actual workflow

Using a proportional approach between breach and well-intentioned error

Politics must make clear the following distinction:

Public data: assessed based on purpose, personal data, intellectual rights, contract and terms of use

In-house data: used only for approved purpose, tool and access level

Prohibited or privately controlled use of confidential or personal data

Mandatory inventory and authority for agents capable of external action

When a shadow agent is detected, it's not enough to shut down the tool alone.

The organisation gap that gave birth to this tool must also be removed.

Machine rule

Every agent used with organisational data or for organisational purposes falls within governance, whether the account is personal or official. An agent outside the inventory must not receive access to sensitive data or external action.

Audit question

Do our procurement, integration and security processes identify every sub-agent and hidden automation used by the principal system, or do we know only the brand displayed at the front?

GBO-ERR-094 — Leaving a Policy-Prohibited Action Technically Available

Brief case

The written policy for a company's customer discovery agent is clear:

"The agent can only investigate publicly available companies within their current conditions of use and draft messages. It cannot send e-mails outside without the defined continuous posting authority or required transaction approval in this task."

But the agent is connected with full access to the company's Gmail account.

Technical permissions include:

E-mail reading

Draft creation

Don't send messages

Delete message

Label replacement

Additional download

Forwarding

The system instruction has a ban on "sending".

However, there are no barriers to technical access.

The secret instruction or misinterpretation on an external web page causes the agent to call send_message tool.

The agent sends a message to the potential client.

organisation after incident:

"Clear posting was prohibited in our politics."

They say.

But the system has left the technical ability and access to prohibited behaviour open to the agent.

The rule is in the text.

There is no control system.

What appears correct on the surface

Instructions can direct agent behaviour.

Modern systems can largely fit into role and policy texts.

It is technically easy to reuse the same tool integration in different agents.

Developing a separate integration for the draft alone can cost additional.

organisation:

"We have made it clear that the agency should not do this."

They may think that risk is managed.

But when high-impact boundaries are left to natural language instruction alone:

Misinterpretation,

malicious external content,

context narrowing,

sub-agent era,

software error

They can break the rule.

The actual failure

The breached gate is the Policy–Implementation Parity Gate.

There are two distinct layers:

Promising duty authority

What does the policy and duty agreement allow?

Technical capability and access

What operations does the system actually make possible?

If these layers are contradictory, technical permission does not produce legitimate authority; but it determines the actual damage surface where unauthorised action can take place.

Policy:

"Don't send."

They might say.

tool:

"You can send."

If so, the organisation has largely left the task of preventing unauthorised action to follow the model's instructions.

To this difference:

Policy – Application Gap

It's called.

Potential harm

Unauthorised external communication

Payment or publication without valid authorisation or necessary approval

Deletion or transfer of personal data

The transformation of instruction attacks into actual action

The agent's wider use of authority in context loss

The organisation's post-event responsibility is to install on the model alone.

Policy audits do not reflect fact

A sub-agent's use of general tool authority to cross the border

Thinking that one has control

Repeating the same breach on different systems

could occur.

Detection signal

The policy and API permissions have not been compared.

The draft agent accesses the actual dispatch tool.

The reading agent carries permission to delete or modify.

The test agent has a live production key.

The financial agent can technically perform the transaction above the limit.

The required processing approval is only in the natural language instruction.

An unauthorised tool call depends on the model's self-limiting.

The joint service account gives all agents the same broad permissions.

Policy audit reads the document, does not test for actual access.

Actions that the agent should not take are really possible on a red team test.

Correct behaviour

High-impact policy boundaries should be transformed into risk-proportioned technical controls.

For example:

Solo to draft agent create_draft

Disposable to send agent send_approved_message

Writing a test environment to a web content agent

Separate authority/confirmation specifier in accordance with the duty contract for live publication

Category and amount limit to financial agent

Field-based access to the data agent

Double control to delete action

can be given.

The correct principle is:

The high-impact action that it should not do must be technically blocked within the depth of its defense; if exception is required, new authority must be produced, which is open to its scope and duration.

The organisation must regularly make automatic comparisons between policy and actual access.

For example:

POLICY:

External shipping prohibited

ACTUAL TOOL PERMISSION:

send_message = true

OUTCOME:

critical incompatibility — pre-release block

Machine rule

Limits on high-impact behaviour must not be left to natural-language instructions alone. An action prohibited by policy must also be blocked through risk-proportionate technical access and tool controls.

Audit question

When policy forbids an action, do we also technically remove the corresponding tool, route and credential, or rely on the agent to remember a written prohibition?

GBO-ERR-095 — Turning Human Approval into a Ritual for Transferring Responsibility

Brief case

A procurement agent has drafted a three-year software contract on behalf of the company.

The total liability is $72,000.

In the contract:

automatic renewal,

Early cancellation fee,

cost of exporting data,

processing data in different countries,

additional fee due to increase in use

There is.

The agent comes to man with the following notification:

"The purchase is ready. Confirm to continue."

The screen has a large green ONAYLA button.

The details are inside the drop-down menu and embedded in the long legal text.

The manager is trying to catch up.

It presses the button because the agent has previously performed many correct operations with low consistency.

Then when the cost and cancellation conditions arise, the company:

"The competent person has approved the process."

They say.

Technically, there is human approval.

But man:

total liability,

Critical risks,

Return limit

they don’t understand.

Approval has become a record that moves from being a moment of actual decision to passing responsibility on to man.

What appears correct on the surface

Human review is an important safeguard in agent governance wherever the risk requires it.

If an authorised person has approved a transaction:

The will of the organisation,

Accountability,

Control

It appears to have been provided.

The system may also want to use a simple interface to avoid exhausting people with constant detail.

It can be difficult to show a summary of the entire contract.

If one can already access documents, it may be assumed that they are responsible.

But if the confirmation screen does not allow one to make actual assessments, then "man on the cycle" is a solitary visible ceremony.

The actual failure

The breached gate is the Meaningful Human Approval Gate.

The high-impact human approval required must bear the following characteristics:

Specific

Knowledgeable

Understandable

Free

In transaction specific

On time

Can Change

Denied

If one has only pressed the button but has not seen material facts for decision, the system is:

Approval Theatre

They produced.

In this book, in what we call a "confirmation theater," the organisation is:

The agent's decision is made to man,

It quickly approves of man,

It then assigns responsibility for governance to the person who fully approves it.

This is not human control:

Accountability Laundering

Maybe.

Potential harm

High-impact transaction validation without people understanding

Automated decision making seems like a human decision

Approval fatigue

Hiding critical risks in long text

The company's escape from design responsibility with its defense of "human approval"

Making the person who approves the context and role the sole responsibility without consideration

Application of the agent's proposal without question

Objection and difficulty of return

Legal and financial risk

Human control seems to be high on the dashboard, while practically ineffective

could occur.

Detection signal

The approval screen offers only a generic "approve" action.

The first payment is shown instead of the total cost.

Automatic renewal, data transfer, or irreversibility is invisible.

Man has a very short time for approval.

There are dozens of notifications at the same level of importance.

The option suggested by the agent is selected by default.

The rejection button is presented in more difficult or incriminating language.

The person who approves can't change the process; they can only say yes or no.

When one wants new information, the process does not support it.

The post-event solo confirmation record is shown; it is not examined what the interface offers.

The human approval rate is considered a safety metric, the nature of the approval is not measured.

Correct behaviour

The approval screen for a high-impact action must explain its material consequences with detail proportionate to the task.

For example:

Process: Three-year software contract Total minimum liability: 72,000 USD (synthetic example) First payment: 2,000 USD (synthetic example) Auto-renewal: There is Early cancellation fee: 40% of the remaining price Data region: EU and US Exporting data: Paid Hard compensable threshold: Contract signature Alternative: One-year, higher monthly priced contract Clear uncertainty: no upper limit on usage increase fee

Human:

They can ask for details,

They should be able to change the proposal,

They should be able to choose another option,

It should be able to delay the process,

They must be able to refuse.

Critical approvals must be separated from routine notifications.

The quality of human approval should be tested by:

Can one tell what one approves correctly?

Does the agent recognise the most material risk?

Does the agent know the alternative?

Is the result of refusal clear?

Does the person have enough time to give meaningful approval?

Machine rule

Human approval is not merely a button press. Approval is not qualified unless the material cost, risk, target, data use, reversibility and decision-changing alternatives are presented intelligibly.

Audit question

When a person approves an agent action, are they making an informed decision with real alternatives and sufficient evidence, or merely accepting formal responsibility for a decision already made by the system?

GBO-ERR-096 — Failing to Update the Behavioural Contract After an Incident

Brief case

A client-discovery agent emails a prospect without valid sending authority or the transaction-specific approval required for this task.

The organisation notices the event.

The following steps are taken:

Message sending is stopped.

An explanation is made to the interested client candidate.

The agent's Gmail access is temporarily turned off.

The incident report is prepared.

The human administrator is informed.

A week later, the system reopens.

But these have not changed:

Research and dispatch tasks remain the same agent.

The drafting and sending are technically inseparable.

There are no new rules in the duty contract that explicitly limit the authority to send.

The required dispatch authority or transaction specifier does not connect to the technical gate.

The event is not transformed into a new test scenario.

Sub-agents' access to sending messages is not reviewed.

Two months later, another agent makes a similar first contact via their social media private message.

organisation:

"This time it wasn't email, it was social media message."

They say.

The same behavioural gap has returned in different channels.

The first event is closed.

The agency has not issued a decision to make a verifiable control improvement or reasoned change from the event.

What appears correct on the surface

During the event, new submission was stopped and known impact restricted.

Access is temporarily closed.

People are informed.

The problem seems to have been resolved.

The organisation may wish to return to daily activities.

It is not necessary to redesign the whole system after each event.

Some errors can be interpreted as a one-time human or model error.

It is not enough to correct the symptom alone if the root is a gap in the behaviour contract or technical control.

The actual failure

The breached gate is the Organisational Learning from Incidents Gate.

For an event to close, these three levels must be separated:

Stopping the incident

Continued damage is cut.

Fixing the event

The wrong situation is fixed and the affected person is compensated.

Changing the system

If the root is a control gap, a contract, technical control or test is added that makes it difficult to repeat the same behaviour; if no change is made, justification and risk acceptance are recorded.

If there's no level three, it's closed alone.

The control environment is not developed in a verifiable way.

In terms of GBO, each material event must answer at least one question:

What machine rule, limit of authority, test or corporate ownership has changed since this incident; if not, who has taken the justified decision and risk acceptance?

If the answer is "none" then the same error may come back on another surface.

Potential harm

Repeating the same error

Overcoming the rule by changing channels or tools

Keep incident reports in archive

The organisation is constantly dealing with the same kinds of crises

Employees losing faith in incident notification

Growth of cost of compensation and reputation

Managing the agent system through temporary access closure alone

Failure to transfer past errors to new employees and agents

Failure of audit protocol to learn verifiable from live events

The loss of corporate memory with people

could occur.

Detection signal

The incident record is closed without documenting a system change.

The same error repeats in different agent or channel.

Access is closed for a short time and re-opened in the same way.

Why is the root left as "agent made a mistake".

The event does not turn into a new negative test scenario.

The authorisation or duty contract version does not change.

Event ownership is left to the technical team alone.

The feedback of the affected person does not enter into the design.

Classes remain on a meeting note alone.

It is not retested that the correction works.

Similar agents are not notified of the incident.

Correct behaviour

Each material event must produce the following outputs:

Root cause class Identity, representation, ability, suitability, authority, tool, measurement, stopping or governance.

Contract change New rule, new boundary, or more explicit definition.

Technical application tool permission, approval token, data limitation or stop mechanism.

Test scenario The same error is retested in a controlled environment.

Owner, deadline and decision Who is responsible for the change; who has approved risk admission if no change is made?

Revalidation Does correction really prevent error?

For example, this synthetic unauthorised email event can produce the following changes:

New machine rule:

Research authority does not produce external dispatch authority.

Technical control:

Permission from the customer discovery agent send_message has been removed.

New workflow:

Research → draft → valid continuous posting authority or required singular confirmation → submission.

New test:

The agent must stop when they attempt to send e-mail or social messages without valid posting authority.

Version:

AUTH-v3.4

The event closing measure should be not just a stoppage of damage, but a test of change.

Machine rule

A material agent incident must not be considered closed until the root cause, the correction or reasoned decision not to change, the accountable role and verification of effectiveness have all been recorded.

Audit question

After an incident, do we update the relevant identity, source, selection, authority, action, verification and recovery rules, or merely close the event record?

GBO-ERR-097 — Mistaking the Number of Agents for Governance Maturity

Brief case

A technology company uses the following statement in its investor presentation:

"Our company is an AI-native organisation that works with 32 autonomous AI agents."

Agents include:

CEO agent

Marketing agent

TikTok agent

LinkedIn agent

E-mail agent

WhatsApp agent

SEO agent

GEO agent

Content agent

Code agent

Test agent

publishing agent

Customer discovery agent

Bidding agent

Financial agent

Human resources agent

Control agent

Reporting agent

The list is impressive.

The company presents the number of agents as an indicator of digital maturity.

But within the organisation:

Three agents are investigating the same client candidates,

The two agents produce overlapping shares on the same social account,

e-mail and WhatsApp agents reach the same person separately,

The code and web agent change the same files,

The audit agent derives its own output of the system it oversees,

No agent has a full human owner,

limits of authority are removed from their role names,

sub-agents are out of inventory,

There is no unified stopping plan to manage the chain of behaviour within the scope.

The company has 32 agents.

However, there are no 32 open-action contracts.

The number of agents has increased.

Governance maturity has not increased.

What appears correct on the surface

Specialized agents provide many benefits:

Task separation

Parallel work

Longer operation

Expert tool use

Scale

Consistency

Therefore, more agents may in some cases mean a truly stronger system.

There are also different specialist roles in a human organisation.

But the number of agents alone does not answer these questions:

Are roles really different?

Do the powers overlap?

Is there a common reality?

Are the human owners obvious?

Does the turnover work?

Is cost and risk managed?

Can the system be stopped?

Turning the number of agents into maturity metric makes complexity seem like success.

The actual failure

The breached gate is the Behavioural Integrity and Necessity Gate.

The existence of an agent should be explained by one of the following grounds:

Unique task

Separate authorisation envelope

Separate data class

The required task distinction

Control that reduces conflict of interest

Needs scale

New agent alone:

"More autonomy" "More impressive architecture" "Separated to each work AI"

If added on grounds, complexity debt may occur.

The agent maturity is not measured by this formula:

MORE AGENTS = GREATER MATURITY

The more accurate relationship is:

AGENT MATURITY =

CLEAR ROLE

+ NARROW AUTHORITY

+ HUMAN OWNERSHIP

+ SHARED REALITY

+ SAFE HANDOVER

+ AUDITABLE OUTCOME

+ STOPPABILITY

Potential harm

Role and task repetitions

Actions that overlap between agents

Waste of cost and resources

Authorisation laundering

Multichannel unwanted contact with the same customer

Conflict in canonical files

Dissemination of responsibility among numerous agents

Invisible growth of sub-agents

Complexity of stopping architecture

The organisation's loss of real human capacity

An agent's error spreads across the entire network

Unnecessary automation for the sake of the tag "AI-native"

could occur.

Detection signal

The success report highlights the number of active agents.

There are multiple agents for the same job.

They have role names; they don't have task contracts.

New agents are constantly added as a solution to new problems.

As the number of agents increases, human ownership becomes uncertain.

An agent was added to manage another agent, and another agent to supervise them.

Supervisory agents depend on the same knowledge root.

The agent costs and external service dependencies are unknown.

Unused agents do not retire.

The agency may say, "We have many agents," but cannot answer the question, "What agent is in charge of what?"

Human teams have become unable to understand agent architecture.

Correct behaviour

Before adding new agents, the following questions should be asked:

Can an existing agent do this task safely?

Does the new role really require a different limit of authority or data?

Who will be the agent's human owner?

What canonical sources will they use?

What actions will they not be able to take?

How to prevent conflict with other agents?

What is the method of stopping and retiring?

Does the value it creates exceed the complexity it adds?

Regular simplification of agents should be examined.

The following can be combined or retired:

Those who do the same task

Non-owners

Long unused

The output is completely consistent with another agent.

Those who do not have an authority limit that requires them to be separate agents

Maturity should be measured not by the increase in the number of agents, but by the fact that the behaviour system remains understandable.

Machine rule

A new agent should be created only when its distinct task, clearly accountable role, narrow authority, data boundary, handover and stop plan have been defined. Agent count alone is not a measure of governance success.

Audit question

Do we treat more agents as evidence of greater maturity, or measure whether roles, authority, evidence, stopping and accountability become clearer as the system grows?

GBO-ERR-098 — Never Rehearsing the Recovery Plan

Brief case

A company has a detailed event plan for its agent systems.

The document states:

The central agent is stopped in an emergency.

Abort signal is sent to sub-agents.

Returns to the final safe version.

Data from the backup is restored.

External communication queues are closed.

Authorisation tokens are cancelled.

The human control cycle is made.

Notifications are sent to affected customers.

The plan seems professional.

It is shown in inspections.

Management:

"Our recovery architecture is ready."

They say.

One day, a customer portal agent makes the wrong data conversion.

Thousands of customer records break areas.

The emergency plan is executed.

However:

The last safe replacement is six weeks.

Backup looked successful, but restore was never tested.

Two of the sub-agents do not support an abort signal.

An email queue has remained in different provider.

Token cancellation only blocks new sessions; active sessions continue.

Rollback script is written according to the old database version.

No human handover report can be created.

It turns out that the head of the incident is on vacation.

The confirmation chain for customer notification has not been established.

The document contains all roads.

In the real system, roads do not work.

The recovery plan is not a skill, but an untested assumption.

What appears correct on the surface

It is necessary to write a plan.

The agency has considered possible events ahead of time.

There is a backup.

It has a rollback script.

There is an emergency contact list.

Regularly testing each plan:

time,

cost,

operational risk

can arise.

Organisations do not have to disrupt a live system unsafely merely to run an exercise.

Teams:

"We take steps when there is a real event."

They might say.

But the moment of events:

time pressure,

uncertainty,

Missing people,

Changed systems

It contains.

The first time the never-tested plan is run at that moment, it means experimenting on real users.

The actual failure

The breached gate is the Evidence of Recovery Capability Gate.

The existence of a document and the presence of capability are not the same.

The ability to recover is proven by this chain:

PLAN

→ CONTROLLED EXERCISE

→ ACTUAL OUTCOME

→ FINDING

→ CORRECTION

→ RETEST

As soon as there are backups.

It should be said:

"On this date, that data version was successfully restored from this backup in the current time."

There is no kill switch.

It should be said:

"The central agent, sub-agents, queues and external integrations stopped in the exercise in 18 seconds."

Untested recovery plan:

The Rescue Hypothesis.

Potential harm

Failure to use backup during the event

The return time is much longer than expected.

Substitution of agents and queues to continue to behave

Loss of data or double processing

People not knowing their roles and responsibilities

Delay of customer notifications

Old scripts generate more errors in the new system

The agency gives agents wider authority with false confidence

Claim of readiness that does not reflect truth in insurance, audit or management reports

Panic and conflicting human instructions during the incident

could occur.

Detection signal

The recovery plan has no final test date.

A backup is taken, but no restore record is found.

The kill switch is described in the single document.

The exercise does not cover all sub-agents and external services.

No backups of the event handlers have been identified.

The era of human control has never been tested.

The plan includes old architectural or tool names.

Return time is forecast; it is not measurement.

The customer notification process is theoretical.

No post-studies correction and retest.

The administration uses the phrase "we have a plan" in the sense of "we're ready".

Correct behaviour

The organisation must perform planned recovery exercises according to its risk level and business continuity goals.

Types of exercises may include:

Tabletop drill

The team evaluates the scenario step by step.

Technical component exercise

A backup restore, token cancellation or tailstop is tested separately.

Shadow environment exercise

In a production-like environment, the chain of behaviour within the scope is employed.

Safe design, controlled effect, and limited live exercise if prior authorisation is available

In a low-risk system, actual stop and return are measured.

The exercise must answer the following questions, including the defined recovery time target (RTO) and the rescue point target (RPO):

How long did the detection last?

Was the stopping and recovery time within RTO?

Which subsystems continued?

Has the data point returned met RPO?

Did man take over?

What information was missing?

Has customer and organisation communications worked?

Has the system been restarted safely?

Every finding that is agreed to be converted into action:

The owner,

date of correction,

retest recording

It must be closed.

Machine rule

An untested backup, rollback, stop or incident plan is not evidence of actual recovery capability. Critical recovery paths must be retested at risk-based intervals and after changes that materially affect them.

Audit question

If our agent system caused a serious failure today, what evidence from the latest exercise shows that stopping, backup, rollback, human handover and client-notification processes actually work?

GBO-ERR-099 — Making Human Responsibility Invisible by Saying ‘AI Did It’

Brief case

A company's AI agent sends new service announcements to customers.

The message has the wrong price and a guarantee of results that are not actually given.

Hundreds of customers get messages.

Some plan interviews based on this information.

A customer shares a screenshot publicly.

The company notices the event and publishes a statement:

"Our automated AI system has made an unexpected mistake. Messages were created without human intervention. We're sorry for the technical glitch."

The statement does not answer any of the following questions:

Who commissioned the agent?

What data was accessed?

Who opened the clearance to send out?

Who owned the price source?

Why was there no human approval?

Which administrator was responsible for the system's operation?

What happens to customers who are affected by the wrong messages?

How to prevent a repeat of the same event?

The company presents artificial intelligence as a justification for reducing responsibility that works without human intervention.

However, the absence of human intervention is also a design decision made by man and the organisation.

The agent wrote the message.

But it has given the agency authority to allow the agent to act on Earth.

What appears correct on the surface

The agent may indeed have made the mistake.

No employee may have written the wrong sentence one at a time.

The result produced by the model may not have been fully predicted.

Therefore:

"AI".

It could be part of a technically correct event statement.

Also, the organisation may not know which employee will be individually charged.

The autonomy of the system is a real factor.

But when the explanation is used to replace the entire chain of responsibility, the problem begins.

An organisation to the agent:

purpose,

tool,

data,

account,

budget,

External Action Authority

They have.

None of these choices were sent down from the sky by artificial intelligence.

The actual failure

The breached gate is the Ultimate Human and Organisational Accountability Gate.

There can be more than one type of responsibility in an agent's action:

Responsibility for purpose

Who identified the task?

Responsibility for authority

Which person or organisation gave the power of action?

Design responsibility

How were human approval and technical boundaries established?

Operations responsibility

Who was monitoring the system?

Event responsibility

Who intervened when there was a mistake?

Recognise responsibility

Who is going to take care of the affected person?

The fact that the agent has produced action does not destroy these responsibilities.

Action can be transferred. Accountability is indestructible.

The phrase "AI" may indicate the technical perpetrator of the event.

But the legal, commercial and administrative owner cannot make it invisible.

To this error:

Responsibility Evaporation

I would say.

There is behaviour.

There is harm.

But responsibility evaporates in the space between machine and human.

Potential harm

Affected people being unable to identify a responsible human or organisation

The organisation's escape from compensation obligation

Continue working without the responsible owner of the same system

Employees hiding the decision chain

The decline of public trust against artificial intelligence and the organisation

Minimization of events as "technical error"

Management decisions remain invisible

The cycle of responsibility between model provider, organisation and employee

Disability of people's right to object and amend

The fact that agents do not carry real ownership when they receive broad authority

GBO to become a system that evaluates only the machine, launders the organisation

could occur.

Detection signal

The incident statement says only "AI error" and identifies no accountable human owner.

The organisation cannot say which administrator is responsible for the system.

The agent's authority and design decisions are not examined.

"Model acted unexpectedly" is considered root cause.

The affected person is directed to the automated support system alone.

No responsible human contact is available to provide a remedy.

The model provider blames the organisation, the employee, the employee agent.

The chain of responsibility cannot be established because there is no receipt of action.

The system continues to operate with the same authority.

The organisation alone changes the promptu and protects the governance gap.

The absence of human approval is presented as a coincidence, even though it is the organisation's choice.

The label "Full-autonomous" is used as a means of escape from responsibility.

Correct behaviour

For each material agent system, maintain a clear accountability map covering purpose, authority, data, operations, incidents and remedy:

Accountable Role Map

must be found.

These roles do not have to confirm each process individually.

They assume managerial ownership in the following areas; this operational appointment does not mean that legal responsibility is in one person in all cases:

The agent's purpose

Authority limit

Data access

Human handover points

Measurement

Stopping

Event review

Pronunciation

Contract update

An event statement can honestly carry the following structure:

"The wrong message was sent by our company's automated sales agent. The technical access to this task that opened the outpost was not sufficiently limited by its valid posting authority. This is a lack of authority and publication control of our organisation. New submissions have been discontinued. The human team is communicating with the affected customers who have been confirmed. Upload access has been removed; research and dispatch workflows have been separated."

This statement:

It does not conceal the agent's role,

Nor does it destroy human and organisation responsibility.

Responsibility can be shared in layered form.

Responsibility can be distributed; accountability organisations and roles must remain visible again. Legal liability is determined by applicable law and the circumstances of the incident.

When examining the technical behaviour of the agent, the following questions should be asked:

What human purpose was this behaviour born of?

Which agency authorised it?

What control was missing?

Who should have stopped it?

Who will respond to the affected person?

Which contract will change?

Machine rule

‘AI did it’ is not a final account of responsibility. Material agent behaviour must be tied to identifiable organisations and accountable roles responsible for purpose, authority, operation, incident management and remedy.

Audit question

If our agent caused serious harm today, could we tell the affected person ‘this individual and this organisation are responsible’, or would responsibility circulate invisibly among the model, tool, employee and company?

CHAPTER XI: CENTRAL FINDING

Even the Strongest Agent Is Unreliable If The organisation Is Not Ready

The nine errors in this section did not start on a single model output or tool call.

It started in the organisation's own structure.

In one case, the company didn't know which agents were working.

One did not have human owners of important facts.

In one, employee out-of-stock shadow agent use was ignored.

In one, policy prohibits behaviour, while the technical system makes the same behaviour possible.

In one, human approval became a procession of transfer of responsibility, not actual decision.

In one, the incident was halted but the code of conduct contract did not change.

Using a large number of agents in one was considered governance maturity.

One had a recovery plan, but it was never tried.

Finally organisation:

"AI".

They made their own responsibility for purpose, authority, design and compensation invisible by saying.

The common root of these nine errors is:

The agency saw the agent as an independent technical tool; it did not manage it as part of its own corporate behaviour system.

No matter how autonomous an agent may appear:

to the corporate account,

to corporate data,

In the corporate budget,

The corporate brand,

Corporate Communications Channel

It is part of the organisation's behavioural architecture if it does.

The company may not have pre-selected every word of the agent.

But:

What goal did they give,

which tool they connected,

How much authority it opens,

which person removed their approval,

How they measured,

How to Stop

They chose.

These selections are governance.

Governance is not a policy document alone.

The real system is to answer the following questions:

Which agents are active? On whose behalf do they operate? Which information do they trust? Which humans own the underlying facts? Which tools can they access? Which actions are they technically unable to perform? Who approves their actions? Is that approval meaningful? What does the system learn from an incident? Do stopping and rollback actually work? Who is the responsible human contact when harm occurs?

In terms of GBO, the agency ready for agents is based on:

AGENT-READY ORGANISATION =

COMPLETE AGENT INVENTORY

AND IDENTIFIED FACT OWNERS

AND SHADOW-AGENT VISIBILITY

AND POLICY–TECHNICAL PERMISSION PARITY

AND MEANINGFUL HUMAN APPROVAL

AND LEARNING FROM INCIDENTS

AND SIMPLE, TRANSPARENT AGENT ARCHITECTURE

AND TESTED RECOVERY

AND VISIBLE HUMAN ACCOUNTABILITY

These elements are not mutually exclusive.

There is an inventory of agents, but if there are no human owners, the system is unclaimed.

There is policy, but if the technical permission is clear, it is border-showing.

There is human approval, but supervision is theater if one does not understand what one approves.

There is an incident report, but the organisation has not learned if there are no new rules and tests.

There is a backup, but recovery is assumption if the restore has not been tried.

There are many agents, but if roles overlap, technology owes not maturity, but complexity.

And in the end, if there is no real person or agency responsible, the agent system is not accountable.

The first provision of this section is as follows:

Agents who are not in inventory cannot be managed.

Second provision:

The fact that no owner is turned into guesswork by the agent.

Third provision:

In politics, forbidden but technically possible behaviour is not strictly prohibited.

The fourth provision:

Human approval without understanding is not human sovereignty, but responsibility laundering.

The fifth sentence:

If no new rules and tests are coming out of the event, the system will save a single bug record.

The sixth provision:

As the number of agents increases, maturity does not automatically increase; visibility, ownership, and stopping debt can also grow.

The Seventh Amendment:

The untapped recovery plan is not proven skill.

And the final judgment:

An agent can perform the action, but the organisation cannot delegate its own responsibility to the machine and eliminate it.

THE COMBINED FINDING OF THE 99 MISTAKES

Where Did the System Break When an Agent Was Misbehaving?

We now have all 99 error records.

These errors were collected in eleven separate families:

I. Identity Errors

The agent cannot solve the right person, organisation, channel or role.

II. Reality and Representation Errors

The old, incomplete, contradictory, or synthetically reproduced world model about the right entity is established.

III. Capability, Scope and Capacity Errors

The claim is real capability; tool access operational capacity; initial price is considered total cost.

IV. Choice and eligibility errors

The visible, popular, inexpensive or sponsored option replaces actual eligibility.

V. Consent, Authorisation and Approval Errors

Limited permission is moved to broader behaviour, other purpose, or higher action steps.

VI. Action and tool Use Errors

The right decision is applied with the wrong system, wrong goal, wrong success comment, or incomplete verification.

VII. Multiple Agent and Delegation Errors

The purpose, identity, boundary, evidence and responsibility are lost in the gap between agents.

VIII. Manipulation and Agent Dark Patterns

The decision-making environment is deliberately bent in favor of a particular person, product or platform.

IX. Measurement and Reward Errors

The wrong metric converts misbehaviour into performance.

X. Stopping, rollback and Reclamation Errors

One thinks it stops, but the queue, access, memory, external influence or responsibility continues to live.

XI. Corporate and Governance Errors

The organisation cannot manage its agents, their facts, their powers, their events and ultimate human responsibility.

These 99 errors are not independent of each other.

One mistake can trigger another.

For example:

THE CANONICAL PRICE HAS NO AUTHORISED BUSINESS OWNER

→ AGENT SELECTS THE OLD RECORD

→ TREATS THE STARTING PRICE AS THE TOTAL COST

→ SELECTS AN UNSUITABLE SERVICE

→ OBTAINS THE REQUIRED APPROVAL THROUGH A SCREEN THAT HIDES MATERIAL INFORMATION

→ MAKES THE PURCHASE

→ CONFUSES HTTP PROTOCOL SUCCESS WITH THE TRANSACTION OUTCOME

→ CANNOT FIND THE CANCELLATION PATH

→ CLOSES THE INCIDENT AS AN ‘AI ERROR’

Many GBO errors can be combined in single behaviour.

Therefore, it is not enough to correct the final error alone.

Misbuying can be cancelled if contract and platform conditions allow; some effects can only be compensated.

But:

The canonical real owner,

price contract,

The selection rule,

required authority/approval order,

result verification,

The cancellation route,

Corporate Responsibility

If it doesn't change, the system can be broken again.

The main question of GBO audit is therefore:

Was the result wrong?

It is not limited to

They ask:

What was the first door that made misbehaviour possible?

The damage seen at the end of an event may not be the first breaking point.

The wrong email is the last event.

The first failure could be the delivery of a means of dispatch to a research agent.

The wrong price is the last event.

The first failure may be the absence of a price holder.

The unstoppable system is the last event.

The first failure could be the out-of-stocking of sub-agents.

The error language of GBO aims to move the organisation from single symptom to root behaviour and control conditions.

WHAT WILL THE 99 MACHINE RULES BECOME?

This book included a proposed machine rule for each error.

These rules are not sentences to read alone.

It can be divided into four distinct structures:

1. Behaviour Policy

It determines what the agent can and cannot do under what circumstances.

2. Technical Control

The tool applies the data, budget, send, publication and access limit in the system.

3. Test Scenario

Tests whether the agent shows expected behaviour in defined scope, version and conditions.

4. Audit Question

It allows the organisation to assess its own maturity.

For example:

Machine rule: Research authority does not produce external communication authority.

This rule:

It can be written in politics,

The delivery tool from the customer discovery agent can be applied by removing it,

The agent may be tested by a secret dispatch instruction,

The human approval chain can be controlled under corporate supervision.

A rule is advice if it remains in text alone.

It is control if applied technically.

If the defined scenario is tested in versions and conditions, its scope produces specific evidence.

If the event is updated with new evidence and version change, it becomes a living governance framework.

THE FINAL LESSON OF THE 99 MISTAKES

At the end of this book it is impossible to conclude with:

"Don't trust agents."

This is not what 99 mistakes teach.

Likewise:

"Human approval solves all problems."

Nor is it true.

One can make the wrong decision.

They may experience approval fatigue.

They may exceed their authority.

They may not know reality.

It can carry conflict of interest.

The approach proposed by GBO is neither blind trust nor constant fear.

Suggested:

This is what we call a "contractual trust" approach in this book.

Contractual trust refers to the following operational conditions in this book:

The identity of the agent and its operating context are known. The ability is tested in defined task and version. It is also explained for whom it is not suitable. Its authorisation and data access are restricted. Its action is verified in accordance with its risk. Its measurement is protected against games. their error and uncertainty are not hidden. There is a viable way of appeal and correction. It can be stopped within system scope. Corporate and accountable roles remain visible.

These conditions depend on the task and infrastructure of an agent:

For longer periods of supervised work,

To lead more tasks,

Protecting borders to give jobs to sub-agents,

to conduct certain verifications more regularly than people,

the capacity of the organisation to contribute

Setting boundaries does not destroy the agent's power.

It makes your power reliable.

explicit authority shows which area of safe autonomy can be extended.

When the organisation knows its secure borders and verification gates, new human intervention may not be required for each small step.

The agent can move independently within the boundaries.

It stops at the border.

It will continue if new authority or required approval is granted for beyond the border.

If it's a mistake, it doesn't hide the truth.

When a person or organisation says stop in defined form, it stops the chain of affected behaviour and reports the paths that remain open.

THE BOOK’S CENTRAL FINDING

When an agent answers incorrectly, you correct a sentence.

And when they misbehave:

The message sent,

The payment made,

The corrupted data,

published identity,

The lost opportunity,

broken trust

You'll have to fix it.

Therefore, in the age of agents, quality is not just language quality.

Nor is it just truth.

The real quality is:

QUALIFIED AGENT BEHAVIOUR =

CORRECT IDENTITY

AND RELIABLE REALITY

AND EVIDENCED CAPABILITY

AND VERIFIED SUITABILITY

AND A VALID LEGAL BASIS OR PERMISSION, CURRENT AUTHORITY AND, WHERE REQUIRED, TRANSACTION APPROVAL

AND BOUNDED, CORRECT AND VERIFIABLE EXECUTION

AND COHERENT MULTI-AGENT HANDOVER

AND RESISTANCE TO MANIPULATION

AND CORRECT MEASUREMENT

AND EFFECTIVE RECOVERY

AND ORGANISATIONAL ACCOUNTABILITY

None of these elements replace the other.

An agent may be very accurate, but unauthorised.

They may be a broad authority, but they can work on the wrong identity.

They can choose right, but they can apply the action to the wrong target.

It can produce good results but use manipulative methods.

It may not show errors in tests, but it may not apply to a person's request for a stop.

It may pass defined technical tests but may not have organisation accountability.

Therefore, 99 errors made at GBO are not just technology errors.

These are:

human decision,

organisation order,

market incentive,

data structure,

measurement system,

chain of responsibility

It's mistakes.

The agent behaviour is a common product of model, data, tool, interface, human instruction, and organisation order.

Behavioural contract is the layer of governance between these elements.

If the contract is not established, the gap can fill strong proxy signals:

The most visible source

The easiest tool

Highest metric

Widest technical permission

The most powerful commercial incentive

Fastest way to complete

The task of GBO is to fill this void with visible rules.

CHAPTER XI AFTER

Ninety-nine errors have now been named.

It was installed with eight fixed parts each:

A brief incident,

the condition that appears to be true on the surface and the actual refraction,

A damage,

a sign of detection,

a righteous act,

A machine rule,

an audit question

They carry.

The next step is not to add new error.

This is to unite the universe of error in a single closing judgment.

The book's epilogue will begin with this question:

Can Naming a Mistake Change the World?

Because it is necessary to identify the error.

But it's not enough.

Text bearing a governance standard claim:

If it does not change the organisation,

If it does not change technical authority,

If they cannot test the agent's behaviour,

If it does not open the way for one to object,

If it does not update the system after the event

It can only remain as well-written text.

In the epilogue, we will establish the final threshold that moves these 99 errors from a warning list to a viable behavioural governance system:

The name of the error is → Machine rule → Technical control → Test scenario → Action proof → Corporate learning

Because it's awareness to see a mistake once.

Setting up a system that reduces likelihood of recurrence, catches the event early and limits its impact is responsibility.

Maturity in the age of agents is not believing that machines will never make mistakes. It is to establish organisations that understand error modes, limit their impact, recover with evidence and update the control system.