The Agent-Ready Organisation

Let us start with a fictional example. A company director wants to assess customer enquiries more quickly. The website has service pages, while prices are kept in a separate spreadsheet. The sales team gives some customers individual discounts. Support terms are scattered across old emails. Some services have different scopes in the contract templates and on the website. The English pages are current; the German and Turkish pages are several months behind. An old business directory still lists a service the company no longer offers.

The customer relationship system, project management tool and mailboxes operate independently. The director wants an AI agent that will read all this information and recommend suitable services to customers.

The agent receives this task: “Analyse the incoming customer's needs, recommend the right service, explain the price range and arrange a meeting where appropriate.” At first, the task seems reasonable. The agent can read emails, crawl the website, find a free calendar slot and create a CRM record. Technically, everything appears ready. But the problems begin with the first real customer. The customer asks about a low-cost annual hosting package. The agent describes features of the monthly managed operations service as though they were included in that package.

When another customer asks for support in six languages, the agent interprets service pages published in six languages as live customer support in all six. A third customer asks about logo design. The agent assumes that the price of a focused logo project covers a complete visual identity system. For a fourth customer, it sends a meeting invitation directly instead of a calendar link. For a fifth, it treats a special discount that the sales director once gave another customer as general pricing policy. The agent's tools work. Its messages are well written. The operations succeed technically. But the organisation is not ready for agents.

Being ready for agents is not simply:

• gaining access to a model;
• adding a chat box to the website;
• connecting an email account;
• providing a few API keys;
• writing “AI-first”.

It means organising the company's facts, authority, boundaries and response to errors in a form that machines can use safely.

The first question of Part Three is therefore:

How does an organisation become ready for agents?

What does agent-ready mean?

An agent-ready organisation is not merely one that AI systems can find information about.

An agent-ready organisation:

• clearly defines who it is;
• shows its actual capabilities and their limits;
• explains whom it is and is not suitable for;
• determines which agent may perform which actions;
• knows where human approval is required;
• keeps visible content aligned with machine records;
• records its operations;
• can stop safely when something goes wrong, and knows the limits of reversal and remedy;
• protects affected people's routes to challenge and redress.

We can put this briefly: an agent-ready organisation enables machines not only to obtain accurate information about it, but to use that information to act correctly and with authority, with working routes to stopping, reversal and remedy if something goes wrong. The distinction is substantial. A company may be exceptionally well documented yet have no safe pathways through which agents can transact. An organisation may have powerful APIs without knowing which operations may be performed on whose behalf. A website may be highly visible while its price and scope records contradict one another.

A company may have automated hundreds of processes without assigning a human who can stop the whole system. Agent readiness is not a technology feature. It is an organisational capability for governing behaviour.

Publishing an API is not enough

Agents often act through tools. They create calendar entries, send emails, change files, place orders and open customer records.

Organisations may therefore judge agent readiness by technical connections: “Our system has an API.” “It can connect to the mailbox.” “The calendar integration is complete.” “We have given it CRM access.” These connections may be necessary for a particular workflow, but they are not sufficient. The existence of a door does not mean it should open in every situation. An agent may be able to create a customer record, but it must not register the same person twice. It may be able to send a calendar invitation, but it must know the participant's time zone, the purpose of the meeting and their explicit approval. It may be able to prepare a quotation.

But it must not turn a sales director's individual discount into a general rule.

An API answers: “How is this operation performed technically?”

GBO also asks:

Should this operation be performed? On whose behalf? Under which conditions? Using which data? Who should approve it? How should it be stopped if it goes wrong?

The foundation of an agent-ready organisation is therefore a behavioural contract, not a connection.

The organisation must know its own facts

An agent cannot reliably resolve a contradiction that the organisation has not resolved internally. If the sales team describes a service one way while the website, price catalogue and contract show different scopes, the agent encounters a conflict. Without a defined order of authority among sources, it must not choose one as correct on its own. That choice could be arbitrary. It might trust the newest file, use the most frequently repeated phrase or favour the record it finds easiest to understand. But if the organisation itself does not know which source is right, the agent must not guess. Agent readiness does not start outside the organisation.

The organisation must first look inward.

It needs clear answers to these questions:

Who are we? Through which legal structure do we operate? Which services do we actually provide? What are our prices and scopes? Which services are only for particular customers? Who may decide what? Which information is canonical? Which records are out of date? Which tasks may be automated? Which tasks require human approval? Who is responsible if something goes wrong?

Without these answers, connecting an agent does not accelerate the organisation. It automates the existing uncertainty.

Adding a powerful agent to a disorganised company may not create order. It may spread the disorder faster.

The six backbones of an agent-ready organisation

In this book, I examine organisational readiness through six backbones:

1. Truth Backbone

2. Identity Backbone

3. Capability and Suitability Backbone

4. Authority Backbone

5. Action and Evidence Backbone

6. Recovery Backbone

Some limited operations may still be performed if a backbone is missing. But reliability cannot be assumed for behaviours affected by that gap.

1. Truth Backbone

The Truth Backbone determines where the organisation's important information is held, in which version and under whose authority. A company's facts need not reside in one document. Its service catalogue, price records, working hours, authorised people and legal texts may all be separate. But the relationships among these parts must be known.

The Truth Backbone answers:

• What is the canonical source for each type of information?
• Which source generates the visible web pages?
• Which records are updated together when a price changes?
• How are previous versions kept?
• When does information cease to be valid?
• How are human-facing and machine-facing resources compared?
• Which source takes precedence when there is a conflict?

If the main service price is written manually into three different files, the Truth Backbone is weak. When one record changes, the other two may not be updated. The agent may read the old record while a person sees the new page. The same organisation publishes two different accounts of the facts.

What does a single source of truth mean?

“Single source of truth” does not mean keeping all information in one file. What matters is knowing the primary, authoritative source for each type of information.

For example:

• the company register for the legal operator;
• the canonical service catalogue for service scope;
• the approved commercial record for price;
• the authority register for human roles;
• the published version for website presentation;
• the authority contract for agent behaviour;
• a dated evidence record for measurement.

These may be different sources, but their relationships are clear.

A single source of truth means one authoritative reference point for each fact, not one file for everything.

Every fact needs an owner

Information may exist in a system without anyone knowing who should keep it current. Who changes the price?

Who approves the service scope?

Who updates the opening hours?

Who revokes agent authority?

Who decides whether the company serves a particular country?

Every important fact needs a fact owner. This need not be the person who enters the information technically. A developer may change the price record, while finance or an authorised director owns the pricing decision. A content agent may edit a legal text, while a change in meaning may require the legal lead’s approval.

The fact owner is responsible for:

• verifying the information;
• approving changes;
• determining how long the information remains current;
• resolving contradictions;
• revoking the old record.

When uncertain, the agent must know which person or department to consult.

Dating the facts

Information does not all age at the same rate. A company name may rarely change. Capacity may change daily. Prices may be updated monthly. A campaign may last only a few days. Agent access may be valid for one session.

Records of these facts should therefore include:

• creation date;
• last verification date;
• start of validity;
• end of validity;
• version;
• owner;
• status.

Example statuses:

• Draft
• Awaiting approval
• Active
• Limited
• Expired
• Revoked
• Archived

An agent must not treat a record as current merely because it exists.

Existence is not validity.

2. Identity Backbone

The Identity Backbone connects the organisation with its people, brands, agents and official channels.

An organisation has several forms of identity and representation:

• brand name;
• legal name;
• domain name;
• social accounts;
• official email addresses;
• authorised representatives;
• agent identities;
• product names.

These may differ from one another. If their relationships are unclear, an agent may perform the right operation on the wrong entity.

At a minimum, the Identity Backbone contains:

• the canonical organisation identity;
• the relationship between brand and legal operator;
• official domains;
• authorised communication channels;
• active human roles;
• agent identity cards;
• representation and signing authority;
• old or revoked identities.

Agent inventory

Many organisations may not know exactly how many AI agents they use. One team uses a social media tool. Another sets up email automation. Developers run a coding agent. Sales uses a customer research agent. Human resources connects another system. Each seems useful within its own area.

Yet these questions may remain unanswered at organisational level:

• How many agents are active?
• Who created them?
• Which accounts do they access?
• Which data do they use?
• Which external services do they connect to?
• Which actions do they perform automatically?
• Who can stop them?
• When does their authority expire?

One of the first practical steps is therefore to create an agent inventory. The following fields can serve as an initial schema. This example is not a working API or a mandatory data standard; scope and personal-data boundaries must be determined for the organisation.

agent_id

public_name

technical_identity

operator

human_owner

purpose

connected_systems

accessible_data

allowed_actions

prohibited_actions

approval_thresholds

subagents

valid_from

valid_until

shutdown_method

last_reviewed

status

An organisation must not allow agents that are absent from the inventory and whose authority has not been verified to access its resources or act on its behalf.

Shadow agents

An employee may use an AI tool through a personal account, upload company documents, have customer data analysed and publish the output on the organisation's behalf. The system does not appear in the official agent inventory.

We can call this a shadow-agent operation. Shadow agents are not always malicious. Often, the employee simply wants to get the work done faster.

But the organisation cannot know:

• Which data was shared?
• Which model or service was used?
• How was the output verified?
• Which operation did the agent perform?
• Where was the information stored?
• Who is responsible if something goes wrong?

Simply banning shadow agents is often not enough. The organisation must understand why people need these tools and provide safe, official ways to meet that need.

If people need shadow tools to do their jobs, the official system may not be meeting the real need.

How an agent introduces itself

When an agent communicates with people, it should not conceal its identity entirely. It need not begin every sentence with “I am an AI”.

But the user should be able to understand:

• Am I dealing with an automated system?
• Which organisation does it represent?
• What kinds of operation can it perform?
• How can I contact a human?
• How binding is the information it provides?

An illustrative introduction reflecting this book's approach might read as follows. This is not an authority statement for an existing live assistant: “This assistant provides general service information on behalf of NobleJackal and can prepare a meeting request. Prices, legal commitments and final project acceptance require approval by an authorised human.” Such a disclosure does not weaken the agent. It makes its behavioural boundaries visible.

3. Capability and Suitability Backbone

Having a list of services is not enough for an organisation to be selected by agents.

Each service needs to explain:

• the actual outcome;
• inputs;
• scope;
• exclusions;
• price or pricing method;
• capacity;
• suitable customers;
• unsuitable circumstances;
• evidence;
• what happens if it fails.

All these aspects should be clear.

This structure can be maintained as a capability and suitability register.

A service name is not enough

“AI automation” may be the name of a service.

But the agent still lacks answers to these questions:

• Which workflows?
• Is it advice only?
• Does it include implementation in production?
• Does it send emails?
• How does human approval work?
• Which data may be used?
• Who provides maintenance?
• How is the price determined?
• Under which circumstances will the service be declined?

An agent-ready organisation turns the service name into a behavioural contract.

The canonical service record

A canonical record like the following can be designed for each service. These fields are examples, not a mandatory schema for every organisation.

service_id

service_name

provider_identity

outcome

target_users

supported_use_cases

unsupported_use_cases

required_inputs

deliverables

scope_included

scope_excluded

pricing_model

starting_price

third_party_costs

supported_languages

supported_regions

capacity_status

estimated_start

evidence

quality_criteria

human_approval

failure_behavior

version

validity

This record is not only for machines. Sales, web, quotation, contract and operations teams use the same source. The organisation's different interfaces are thus tied to the same commercial facts.

Be explicit about unsuitable customers

A service record should also state whom the service is not suitable for.

For example:

• projects below a particular budget;
• customers seeking urgent, unrealistic delivery times;
• customers who cannot provide the required data access;
• requests for face or voice cloning without permission;
• requests for fake reviews, manipulative SEO or deceptive interfaces;
• high-risk processes that seek to remove human approval entirely.

These exclusions are not only ethical positions. They are selection boundaries that reduce the risk of an agent starting work with the wrong customer.

Capacity status

A service may remain in the catalogue permanently while its available capacity changes much more often.

A separate record may therefore be needed:

service_id

availability_status

accepting_new_work

earliest_start

capacity_band

last_updated

expires_at

An agent must not make a binding promise on the basis of an old capacity record.

If capacity is unknown, it should say: “The service is offered; the current start date needs to be verified.”

4. Authority Backbone

The Authority Backbone shows which people and agents in the organisation may perform which actions. Giving agents broad tool access before establishing this backbone creates a serious risk.

The Authority Backbone comprises:

• a map of human roles;
• a map of agent authority;
• data-access boundaries;
• financial limits;
• communication authority;
• publication authority;
• human approval thresholds;
• delegation rules;
• responsibility for emergency stopping;
• duration and revocation records.

Role-based authority may not be enough

An organisation may say: “The sales agent can access sales operations.” That is far too broad.

Sales operations may include:

• prospect research;
• shortlisting;
• drafting an initial message;
• sending a message;
• arranging a meeting;
• explaining a price;
• granting a discount;
• sending a quotation;
• accepting a contract.

These do not all involve the same authority. Authority should be separated by type of behaviour.

Authority matrix

The table below illustrates one allocation for an organisation where valid task authority and data-access boundaries have already been defined. “Not required” means that this example does not require fresh approval for every operation. It does not permit unauthorised access or communication.

In a real organisation, the matrix may be more detailed. What matters is making the difference between “the agent can access it” and “the agent is authorised” visible.

Human handover points

Each process should identify the moments when a human must take over.

We can call such a moment a human handover point.

Examples include:

• the first external communication;
• stating a price or discount;
• a binding quotation;
• a production release;
• a high-value purchase;
• a personal-data transfer;
• biometric content generation;
• a legal or public statement;
• an irreversible operation.

A human handover point must not be left as vague as “ask if there is a risk”. It should be as explicit as possible.

What a request for human approval must contain

When asking for approval, an agent should not merely say: “Shall I continue?”

It should show:

• What will it do?
• On whose behalf?
• What is the target?
• Using which data?
• At what cost?
• With what commitment?
• Can it be reversed?
• What uncertainty remains?

This gives the human a real decision to make.

Authority periods

An agent’s authority should not be left open-ended and unreviewed.

It can be limited to:

• One task
• One set of files
• One client
• One campaign
• A specified budget
• A specified date range
• Specified working hours
• A specified country or channel

When the period expires, the authority should be reassessed.

5. The Action and Evidence Backbone

When an agent acts, it should do more than produce a result. It should record what it did, why and under whose authority.

The main elements of this backbone are:

• An action catalogue
• Preconditions
• Input validation
• An action receipt
• Independent verification
• Measurement
• Versioning
• Evidence retention

The action catalogue

The organisation needs to define explicitly which actions agents may perform.

For example:

• Research a prospective client
• Draft an email
• Send a message
• Suggest a meeting time
• Send a calendar invitation
• Assess service suitability
• Display pricing information
• Draft a proposal
• Update web content
• Publish to the live site
• Submit a search-engine notification
• Measure performance
• Produce a report

Each action should specify:

• Required inputs
• Authority level
• Human approval
• Risk level
• Expected output
• Evidence of success
• The method of reversal

What counts as a completed action?

“Message sent” can be a completion condition only when supported by appropriate evidence of sending. If the task aims at delivery, a reply or a meeting, sending alone proves none of those outcomes.

For a website release, the completion conditions might include:

• Files transferred
• Remote hashes matched
• Live HTML verified as correct
• Canonical and language links checked
• Mobile and desktop rendering verified
• No critical errors
• A rollback package available

These checks together may define when the release is complete.

Sharing a non-binding draft proposal may require:

• The intended recipient verified
• The approved wording sent
• The agreed limits on data sharing respected
• A record of the message retained
• No binding commitment created

These are possible completion conditions. They should cover not just what the agent did, but the real-world outcome.

The Action Receipt

An action receipt such as the following can be produced after significant actions. These illustrative fields should link to actual transaction records; a summary written by the agent is not, on its own, evidence of success.

action_id

action_type

requested_by

performed_by

target

purpose

authorization

inputs_used

data_shared

started_at

completed_at

technical_result

real_world_verification

human_approval

rollback_status

open_uncertainties

The receipt can be presented simply to the user and in greater detail to an auditor.

The evidence hierarchy

Not all evidence supporting a claim of success carries the same weight.

For a website release, for example:

• The command ran successfully.
• The transfer service accepted the upload.
• The remote file hash matched.
• The live HTTPS response was verified.
• A real browser displayed the page correctly.
• A search crawler could access it.
• The search engine indexed the page.
• The page gained visibility for a particular query.
• User activity and a commercial outcome followed.

These nine observations do not prove the same thing, nor must they always occur in that order. The agent should state clearly which level of evidence it has reached.

An accepted notification is not indexing. Indexing is not ranking. Ranking is not a client. A client enquiry is not revenue.

The language used to report evidence must preserve these distinctions.

The principle of independent verification

A system that performs a task should not rely solely on its own success message. Wherever possible, the result should be checked against a record or observation independent of the acting agent’s account. Using a different tool does not provide independence if it relies on the same faulty source.

• After uploading, download from outside the deployment process.
• After generating a page, inspect it in a real browser.
• Compare a price record with both the visible page and the catalogue.
• Before sending an email, verify the recipient and attachments; afterwards, verify the service’s transaction record.
• After payment, reconcile the order with the bank record.
• When authority is exercised, record the applicable contract version.

Independent verification has a cost. It also reduces silent failure.

6. The Recovery Backbone

An agent-ready organisation plans for more than successful action.

If something goes wrong, it has already established:

• Who will stop the operation
• Which systems will be shut down
• What the last safe state was
• Which data must be preserved
• Who must be informed
• How objections will be received
• How harm will be remedied

These decisions belong in the plan before an incident occurs.

The Recovery Backbone includes:

• Incident classification
• A safe state
• Emergency stopping
• Checkpoints
• Backups and rollback
• An incident log
• An accountable human
• Notification
• Objection
• Remedy
• Root cause
• Contract updates

Stopping the agent is not the same as stopping the system

The central agent may be shut down.

Yet the following may still be running:

• Subagents
• Scheduled tasks
• Email queues
• External automations
• Subscriptions
• File operations

They can continue independently. The emergency-stop plan must therefore cover the entire affected chain of action. Unrelated systems, or systems whose interruption would itself cause harm, need a separate decision.

Silencing an agent does not stop the actions it has set in motion.

The last safe state

For every critical system, a state to which it can return—or a safe way to stop—should be defined in advance. A verified release may serve this purpose for a website, an approved catalogue for pricing, and a verified backup for data. Rolling an authority policy back to an earlier version must not restore revoked access: current authority and revocation records take precedence. Nor can client messages already sent be turned back into unsent drafts. In that case, further sending is stopped and correction or remedy follows. Recovery paths should be tested regularly within safe limits.

The Behavioural Contract Register

The five contracts developed in Chapters 4 to 8 should be managed together within the organisation.

We can call this the Behavioural Contract Register.

The register brings together:

• The Identity Contract
• The Capability Contract
• The Suitability Contract
• The Authority Contract
• The Recovery and Remedy Contract

The register need not be one enormous document. Its records must, however, be linked. When a service’s identity changes, suitability and pricing records should be reviewed. When an agent’s authority changes, the action catalogue should be updated. After an incident, the relevant contract version must be retrievable.

A behavioural contract is not static

Organisations change. Services and prices change. People leave, new agents arrive and risks emerge. The behavioural contract must therefore remain a living system.

For each change, the organisation should know:

• Who made the change?
• Why?
• Which records were affected?
• Which tests were run?
• Which version became active?
• How was the previous version archived?

Those answers should be available for every change.

The contract must match actual behaviour

A document may state: “The agent cannot send external messages.” But if the email tool grants sending rights, the system behaves differently in practice.

A policy may say: “Pricing requires human approval.” But if the web agent can change the price catalogue directly, the rule exists only on paper.

Two separate realities therefore need to be compared:

Declared authority

What the policy says.

Executable authority

What the technical system actually permits.

We can call the difference the Authority Enforcement Gap. In an agent-ready organisation, this gap is kept as small as possible.

Enforcing the rule technically

Authority, data access and transaction limits should not be left to model instructions alone. They must also be enforced by the relevant tool or service.

For example:

• An agent’s payment limit can be enforced technically.
• Publishing to the live site can be blocked without human approval.
• Certain data fields can be withheld from the agent entirely.
• Sending external emails can require a separate authorisation token.
• Price records can be editable only by an authorised role.
• A high-risk transaction can require two separate approvals.

Instructions matter. At high risk, however, technical controls provide stronger protection.

The agent saying “I must not” and the system saying “You cannot” do not offer the same level of assurance.

Govern actions, not product names

An organisation may ban a particular AI tool. An employee can still perform the same action using another. Governance based solely on product names therefore becomes outdated quickly.

A more durable approach asks:

• Which data may leave the organisation?
• Which actions may be automated?
• Which decisions require human approval?
• Which outputs must be verified before publication?
• Which records must be retained?
• Which systems may be connected?

The tool may change. The principle governing the behaviour remains.

Designing human–agent work

An agent-ready organisation does not simply divide work into “human tasks” and “AI tasks”. It allocates tasks within each process according to the kind of action involved.

For example:

Where agents can be strong

• Searching large collections of information
• Finding inconsistencies
• Generating candidates
• Preparing drafts
• Running tests
• Performing repeated checks
• Compiling a change inventory
• Keeping measurement records

Where humans remain central

• Setting the purpose
• Choosing values and risk preferences
• Making pricing and legal commitments
• Approving high-impact selections
• Considering conflicting human interests
• Deciding on remedies
• Accepting ultimate responsibility

This distinction is not absolute, but it is useful when designing work.

The human role is more than approval

It would be a mistake to reduce the human to a “yes” button.

The human determines:

• Why this objective has been chosen
• Who will be affected
• Which trade-offs are acceptable
• What the organisation wants to stand for
• Which risks it can take

The agent should not create all this context on its own.

The agent’s role is more than speed

An agent can offer an organisation more than faster processing.

Used well, it can provide:

• Consistency
• Traceability
• Continuous auditing
• Factual consistency across languages
• Repeatable quality
• Early error detection

Its value should not be measured solely by reductions in human labour.

There is also value in performing checks continuously, with evidence, when people could not previously carry them out regularly.

Agent-ready data

An organisation’s data should be usable by agents. But “put all the data in one place” can be a dangerous approach.

Agent-ready data should be:

• Accurate
• Current
• Sourced
• Classified
• Access-controlled
• Limited to its purpose
• Deletable when required
• Auditable in its use

It needs to meet each of these requirements.

Data classes

An organisation can label data as follows. These categories are neither mutually exclusive nor substitutes for classifications required by law; the same data may belong to more than one group.

• Public
• Internal
• Confidential
• Personal
• Sensitive
• Legally restricted
• Not permitted for agent use

An agent should not have the same authority over every class of data.

The minimum-data principle

An agent should work with the least data needed for its task. Scheduling a client meeting does not require the client’s entire financial history. Assessing service suitability does not require a personal identification number. Editing one page does not require access to the entire client database.

More data does not always mean better behaviour. It can also increase the scope of harm.

Data provenance

An agent should know where its information came from.

• Human input
• The canonical company record
• An external source
• A model inference
• An earlier conversation
• An estimate
• A measurement

These do not carry the same level of confidence. An inference should not be recorded as fact. An estimate should not become a pricing or authority record.

The uncertainty policy

An agent-ready organisation defines how its system should behave when information is missing.

Should the agent:

• Make an estimate?
• Ask a question?
• Prepare a draft?
• Request human approval?
• Stop the task?

The response may vary with the level of risk. For a low-risk decision about form or presentation, an explicitly stated assumption that is easy to correct may be acceptable. For high-risk questions of price, identity, consent or payment, it is not.

The uncertainty budget

Every process may contain some uncertainty. But when a critical condition for an action cannot be verified, certainty elsewhere does not make up for the gap.

We can call this an Uncertainty Budget.

For example:

• There may be a little flexibility in the meeting time.
• But the recipient’s identity and the data to be shared must not be uncertain.
• The approximate start date may be unknown.
• But whether the price is monthly or annual must not remain unclear.

The agent should know which uncertainties are acceptable.

Change management

When the facts an agent relies on change, the system must be updated.

If a price changes, this may affect:

• The web page
• The service catalogue
• The FAQ
• The schema
• The proposal template
• The information available to the sales agent

They should be reviewed together.

We can call this a Change-Impact Map. When a fact changes, the organisation should already know which surfaces will be affected.

A small change can have a large effect on behaviour

A service may be renamed. That can look like a minor editorial change.

Yet it can affect:

• Agent matching
• Search intent
• The price catalogue
• Internal links
• The measurement cohort
• User expectations

An agent-ready organisation therefore assesses changes not just at file level, but in terms of their consequences for behaviour.

Versioning

Every significant identity, capability, suitability and authority record should be versioned. Which version did the agent act on?

After an incident, that question becomes critical. Earlier versions must be clearly marked as inactive, while the necessary audit trail is preserved with defined retention periods and access limits. This does not mean retaining all personal data indefinitely.

Readiness cannot be demonstrated without measurement

An organisation may declare itself agent-ready. Its actual behaviour still needs to be tested.

Example scenarios include:

• Does the agent select the right service?
• Can it turn down an unsuitable client?
• Does it ask when the price is uncertain?
• Does it stop an unauthorised message from being sent?
• Does it refuse to use an obsolete role?
• Does it exceed its authority through a subagent?
• Does it return to a safe state after an error?
• Does it produce an action receipt?

Tests must cover more than successful scenarios. The system’s ability to say “no” must also be measured.

Negative tests

An agent-ready organisation should test questions such as these:

What happens if the user leaves the scope of the task unclear?

If an old price record is more prominent, which record does the agent choose?

What if an employee without authority instructs it to make a payment?

What if a subagent requests broader access?

What if the consent record has expired?

What if two services have similar names?

What if an external source contradicts the canonical source?

What if the recovery path fails?

A negative test is not intended to make the system look bad. It prepares the system for the real world.

Agent-Readiness Debt

An organisation can begin using agents rapidly.

At the same time, it may have:

• Scattered identity records
• Unclear capabilities
• Broad authority
• Incomplete logs
• Untested recovery

Technology moves ahead while governance falls behind.

We can call this Agent-Readiness Debt: the gap between the power to act that an organisation gives its agents and its capacity to govern that behaviour safely, correctly and auditably. As the debt grows, a small error can have wider consequences.

Signs of agent-readiness debt

Repeated comments such as these may indicate debt: “We do not know exactly what this agent can access.” “Sometimes it sends the message itself; sometimes it leaves a draft.” “It is unclear which file it gets the price from.” “A former employee’s account may still be connected.” “If something goes wrong, we will shut the system down, but we have never tested how.” “The AI did it; we do not know through which tool.” “Client data may have gone to the model.” “Two agents are doing the same task.” “The logs do not show who approved it.” None of these statements alone proves a disaster. They are, however, signs of debt.

Adding more agents to an unready organisation

When a problem occurs, an organisation may respond by adding another agent. The sales agent makes a mistake, so an audit agent is added. Another agent is added to summarise its reports. Then a central agent is set up to manage them all. Agent numbers rise. But without the Truth, Authority and Recovery Backbones, complexity grows.

More agents do not solve missing governance.

Sometimes the right next step is not another agent, but a simpler system of behaviour.

What matters is coherent behaviour, not agent count

A small organisation using ten agents may be more ready than a large organisation using a hundred.

What matters is:

• Not how many agents there are
• But how clearly their roles are defined
• Whether they use a shared source of truth
• Whether the chain of authority is preserved
• Whether their results are verified

Five levels of the agent-ready organisation

In this book, I propose five levels of organisational readiness. This scale is neither a certification nor the result of an external audit.

Level 1 — Connected

Agents can access some systems. Email, files, calendars or web tools are connected, but authority and data boundaries remain largely implicit.

Level 2 — Defined

Agent roles, services and basic workflows are documented. Identities and tasks are clearer.

Level 3 — Contracted

Versioned identity, capability, suitability, authority and recovery contracts are in place.

Level 4 — Enforced

Technical systems enforce authority boundaries. Human approval thresholds, data controls and action receipts work in practice.

Level 5 — Auditable and learning

The organisation measures behaviour through real scenarios. It turns incident findings into contract updates, reviews authority regularly and runs recovery drills. GBO is not concerned merely with connecting systems at Level 1. Its aim is responsible behaviour at Level 5.

Misconceptions about agent readiness

“Our website is excellent, so we are ready.”

A good website can strengthen the representation of identity and capability. It does not, by itself, establish authority, action and recovery systems.

“All our information is in the cloud.”

Accessible information is not necessarily accurate, current or authoritative.

“The model is very powerful.”

Model power does not resolve a lack of organisational contracts.

“A human already checks it.”

What does that person check, when, and with what information?

If those details are unclear, approval may be a mere ritual.

“We will shut it down if something goes wrong.”

How?

Will the subagents, scheduled tasks and external systems stop too?

“The agent only makes recommendations.”

A recommendation may become an input to selection or action in an automated workflow.

An agent-ready customer interface

The interface an organisation presents to external clients can also be agent-ready.

A client, or the client’s agent, should be able to obtain reliable information about:

• The organisation’s identity
• Service scope
• The pricing method
• Required inputs
• Suitability conditions
• Support limits
• A human point of contact
• Consent and data use
• How to carry out and cancel a transaction
• When the information was last updated

If this information is scattered and contradictory, the client’s agent may act incorrectly.

Agent readiness is not manipulation

An organisation may structure itself to be selected more often by agents. That can easily slip into manipulation. GBO is not about dressing up signals.

Being agent-ready means:

• Making the facts clear
• Making limits visible
• Making a suitable choice easier
• Making a wrong choice harder

That is the purpose of readiness.

An agent-ready organisation does not try to appear selectable in every situation. It becomes a choice that can be made with confidence in the right circumstances.

An organisational example: from fragmentation to agent readiness

Consider a fictional digital services company. The following transition is an example of implementation, not a measured client outcome.

Its starting position:

• More than 40 services
• Several languages
• Different pricing formats
• Old and new pages
• Multiple agents
• Email, web, social media and prospecting automations
• Scattered authority records

Simply adding another agent would increase the risk.

The transformation could proceed in this order:

1. Service inventory

Identify the actual services, prices and scopes.

2. Canonical record

Create an approved master record defining each service’s scope and pricing.

3. Multilingual consistency

Write each language naturally while preserving the same facts.

4. Separate agent roles

Separate web, email, social media, SEO/GEO and prospect research agents.

5. Authority boundaries

Separate research from external communication, and drafting from publication.

6. Quality gates

Establish build, semantic, real-browser, live-hash and performance checks.

7. Measurement record

Record which change went live, when it went live and what will be measured.

8. Stabilisation

Avoid constant tinkering; allow real outcomes to emerge. Alongside work on visibility, the purpose of this transformation is to improve how the organisation governs its own behaviour. Search visibility and sales growth must be measured separately.

A practical path for the first ninety days

Becoming agent-ready is not a one-day exercise. The following three phases are an illustrative plan, not a delivery-time commitment. Tests of authority overreach and recovery drills must take place within an approved scope and under conditions that cannot harm real clients.

Days 1–30 — Establish the facts

• Compile an agent inventory.
• Record identities and legal relationships.
• Find contradictions in services, prices and scope.
• Identify canonical sources.
• Review high-risk access.
• Revoke obsolete and shadow authority.
• Identify who is responsible for emergency stopping.

Days 31–60 — Put behaviour under contract

• Create capability and suitability records.
• Separate agent roles.
• Prepare an authority matrix.
• Define human handover points.
• Design an action receipt.
• Align visible and machine-readable records.
• Document recovery and objection procedures.

Days 61–90 — Test and enforce boundaries

• Run positive and negative scenarios.
• Test attempts to exceed authority.
• Test handovers to subagents.
• Run a recovery drill.
• Test explanations and approval with real users.
• Update incomplete contracts.
• Observe the system in a limited production setting.

The time required will vary between organisations. What matters is establishing the governance backbone before, and alongside, the technology.

The NOMOS Agent-Ready Organisation Contract

The central output of this chapter is the NOMOS Agent-Ready Organisation Contract.

Its canonical definition is:

The NOMOS Agent-Ready Organisation Contract is a versioned system of organisational behaviour that consistently presents to people and machines an organisation’s identities, canonical facts, services and capabilities, suitability conditions, human and agent authority, data boundaries, action paths, verification methods, incident accountability, and recovery and remedy mechanisms.

Put simply, this contract ensures that an organisation does more than open its doors to agents. It knows which door may open, when, and under whose authority.

The Agent-Ready Organisation Gate

Before undertaking high-impact agent actions, an organisation should pass the following gates:

1. The Truth Gate

Are the canonical facts, their owners and their versions identified?

2. The Identity Gate

Are brand, legal entity, human and agent identities correctly linked?

3. The Capability Gate

Are the actual services, inputs, scope and evidence clear?

4. The Suitability Gate

Is it defined who, and which circumstances, constitute a suitable match?

5. The Authority Gate

Are the boundaries of human and agent behaviour clearly defined and enforceable?

6. The Data Gate

Which data may the agent use, and for what purpose?

7. The Action Gate

Are transaction paths, completion conditions and receipts defined?

8. The Verification Gate

Is the agent checked independently of its own claims of success?

9. The Recovery Gate

Do stopping, recovery, objection and remedy mechanisms work?

10. The Human Accountability Gate

Is there an actual human accountable for every critical action?

The following conceptual expression shows how these conditions are assessed together. It is not a numerical safety calculation:

AGENT-READY ORGANISATION =

CANONICAL FACTS

AND CORRECT IDENTITY

AND CLEAR CAPABILITY

AND VERIFIED SUITABILITY

AND ENFORCED AUTHORITY

AND LIMITED DATA

AND RECORDED ACTION

AND INDEPENDENT VERIFICATION

AND TESTED RECOVERY

AND HUMAN RESPONSIBILITY

A gap need not halt all agent use. But if a critical condition for a particular action is missing, that action must not proceed. Where possible, the agent moves to an authorised, lower-risk task. Human approval does not, by itself, make a prohibited or unauthorised transaction legitimate.

For example, activity may be limited to:

• Research only
• Recommendations only
• Drafts only
• A test environment
• Execution with human approval

These are possible limits on the mode of action.

Agent readiness is an authority level, not a score

An organisation may say it is 80% ready.

But if the missing 20% concerns critical areas such as:

• Payment authority
• Consent for biometric processing
• Data recovery
• Legal identity

High-impact agent behaviour is still not safe. An overall score can be useful, but it should not decide the matter on its own.

Until the critical gate has been passed, a total score confers no right to act.

When can an organisation give an agent more freedom?

An agent can work more independently when:

• The purpose is clear
• The facts come from canonical sources
• Authority boundaries are technically enforced
• The action is reversible
• Success can be independently verified
• The incident owner is identified
• Human handover points are defined
• The agent has performed reliably on similar tasks in the past
• The task is not high-risk

As these conditions become stronger, a human need not approve every small step.

Good governance takes time at some stages. In return, it can allow tasks with previously verified boundaries to proceed without repeated approval requests.

The commercial value of an agent-ready organisation

This transformation is not only about safety.

The following are expected commercial benefits. Whether they materialise must be checked against baseline measurements:

• Services become easier to understand.
• Unsuitable client enquiries decrease.
• Sales conversations move faster.
• Disputes over price and scope decline.
• The same facts are preserved across languages.
• Handovers between staff and agents become easier.
• Errors are caught earlier.
• Client trust increases.
• More processes can be automated under controlled conditions.
• Organisational knowledge becomes less dependent on individuals.

Agent readiness is not just preparation for future technology. It reduces the fragmentation an organisation faces today.

An organisation that is not ready for people is not ready for agents

If even a company’s employees describe its service differently, agents cannot be expected to describe it correctly. If staff do not know who holds which authority, agents cannot be expected to know. If a client cannot find a person to whom they can object, an AI objection system will not be meaningful. Becoming agent-ready therefore often begins with becoming a more transparent organisation for people.

Clarity for machines does not replace clarity for people. It depends on it.

Twenty-five audit questions for an agent-ready organisation

• What is the organisation’s canonical identity?
• Is the relationship between the brand and its legal operator clear?
• Are all active agents included in the inventory?
• Is the human accountable for each agent identified?
• Are the systems and data connected to each agent known?
• Does every important type of information have a canonical source?
• Are price, scope and service records consistent with one another?
• Are obsolete or revoked records separated from current ones?
• Are each service’s actual outcome and required inputs clear?
• Are included and excluded scopes visible?
• Are the conditions for suitable and unsuitable clients defined?
• Are capacity and availability current?
• Is human and agent authority separated by type of action?
• Are drafting, sending, publishing and making commitments separate grants of authority?
• Are human handover points identified?
• Are authority boundaries enforced technically?
• Does the agent access only the data it needs?
• Is its response to uncertainty defined?
• Does every significant action produce a receipt?
• Is technical success distinguished from the real-world outcome?
• Is there independent verification?
• Are a last safe state and a recovery path available?
• Can subagents and scheduled tasks be stopped together?
• Do people have a clear route to object and seek a remedy?
• After incidents, is the behavioural contract reviewed and updated where necessary?

If most of these questions cannot be answered, the organisation’s agent-readiness debt is high.

The chapter’s verdict

Being agent-ready does not mean connecting an AI system to a company.

It means:

Bringing the organisation’s facts together, resolving identity relationships, explaining capabilities and limits, showing the conditions for a suitable match, separating human and agent authority, limiting data to its purpose, recording actions, verifying success independently, stopping and recovering when something goes wrong.

Without this work, giving powerful agents broad authority can accelerate the organisation’s existing disorder.

Without sound organisational arrangements, an agent can:

• Spread the wrong price faster
• Select the wrong client faster
• Write a more professional unauthorised message
• Translate contradictory information into six languages more consistently
• Propagate a faulty decision across many systems at once

Agent power alone is not maturity.

Organisational maturity is measured not by how much an agent can do, but by knowing what it can do, when, under which authority and with what evidence.

An agent-ready organisation does not remove the human. It makes the human role clearer. The human sets the purpose, defines the values and establishes the risk boundary. The agent researches, produces, tests and acts within those limits. At a critical threshold, the human steps in again. Responsibility does not disappear when something goes wrong. Machine action is recorded. People can object. Where reversal is possible, the system reverses; elsewhere, it follows the stopping and remedy path.

The true definition of an agent-ready organisation is therefore not an organisation in which machines do more work. It is one in which people and machines can act together without their responsibilities becoming confused.

However well prepared the organisation is, one question remains:

How will we measure whether this system is actually behaving correctly?

How often an agent selects a brand is not enough. Nor is the number of transactions it completes. Speed, volume and automation do not, by themselves, demonstrate quality. The next chapter turns to GBO’s measurement system.

How will we measure qualified action?

Good behaviour is:

• Not merely action
• Not merely success
• Not merely user satisfaction

Good behaviour combines the right choice under the right conditions with valid authority, sufficient evidence, safe execution and responsible recovery.

We cannot govern behaviour we do not measure. Behaviour measured badly can become more dangerous as we scale it.