When an Answer Becomes an Action

Imagine asking an AI system: ‘Find a quiet restaurant for two in Istanbul tomorrow evening.’ The system researches several options, comparing locations, menus, prices and reviews.

It then replies: ‘I found three suitable restaurants. The second appears closer to your preferences for location, noise level and budget.’ This is an answer. The system has assessed the options and given the user information. The user can accept the recommendation, reject it or ask for alternatives.

Now imagine the same system saying: ‘I booked the second restaurant for 8 pm tomorrow.’ If the booking really has been completed, the system has done more than answer: it has changed an external system. Saying ‘I booked it’ does not itself prove that the transaction occurred; the reservation record must be verified separately. A table has been reserved. The restaurant's booking capacity has been affected. The user's name or contact details may have been shared. Cancellation terms may have come into effect. A credit card may have been used. A deposit may have been taken.

Perhaps the booking was made for a date the user never wanted, at the wrong branch or for an unsuitable table. Only a few words in the sentence have changed. If the transaction also occurred, responsibility has acquired another dimension.

A new era begins between ‘I found it’ and ‘I did it’.

GBO's real territory lies between those two expressions.

An answer and an action are not the same

When an AI system produces information, it offers an account of the world. When it performs an action, it changes the world. The distinction seems simple at first. As agent-based systems develop, however, the boundary becomes less clear. Is preparing a draft an answer or an action?

How should we classify filling in a form without submitting it?

Is adding a product to a shopping basket a transaction?

Is creating a calendar invitation merely making a suggestion?

How should we assess editing a file without publishing it?

What separates preparing an email from sending it?

Is requesting a quotation on a company's behalf a non-binding enquiry, or the beginning of a commercial relationship?

Does scheduling a social media post, before it has been published, count as changing the world?

There is no single yes-or-no answer to these questions. Action is not a binary switch. It is a ladder. At each rung, the system moves closer to the world. Commitment and persistence generally increase on the higher rungs. Yet the lower ones are not automatically risk-free: even reading data can affect privacy. GBO therefore asks more than ‘Is there an action?’

It also asks:

What stage has the action reached? Whom does it affect? How far can it be undone? What authority supports it? What consequences could it have?

The Action Ladder

I propose a seven-rung model for examining agent behaviour. These rungs are not a mandatory, uninterrupted sequence; a single operation may involve several at once. The model makes differences in authority and impact visible.

1. Observation

The system gathers information. It reads pages, examines files, compares prices and checks the calendar. It does not yet create a new external commitment. Risks at this stage include trusting the wrong source, accessing information without authority and disclosing data through a query. A read request can also leave traces, such as access logs. ‘Observation’ does not mean the absence of all external effects.

2. Interpretation

The system draws meaning from what it has gathered. It considers a service suitable, classifies an email as urgent, identifies a technical problem on a page or assesses whether a candidate meets particular conditions. If that interpretation remains solely within the system's working context, no new external operation has yet occurred. If the assessment is written to a file, profile or decision record, however, system state changes.

3. Recommendation

The system presents an option to the user. ‘This provider appears more suitable.’ ‘This file needs updating.’ ‘It may be better to reply to this person tomorrow.’ A person is still explicitly at the centre of the decision chain.

4. Preparation

The system drafts the action. It writes the email, fills in the form, prepares the code change, drafts the calendar invitation or assembles the shopping basket. The intended transaction has not yet been completed. But preparation can still change state: a form may autosave, a draft may be uploaded to the cloud, or a basket may reserve stock. Personal data, confidential information or a false commitment within a draft creates a further risk. Preparation is therefore not an uncontrolled zone.

5. Execution

The system carries out the operation. It sends the email, changes the file, makes the reservation, submits the form, releases the code version or sends the calendar invitation. At this point, we are no longer discussing a recommendation alone. The external world has changed.

6. Commitment

The action produces legal, economic, institutional or reputational consequences. A payment is made. A contract is accepted. An order is confirmed. A public statement is published on behalf of a company. A delivery date is promised to a client. A candidate is offered a job or rejected. The system has not merely completed a task; it has created a commitment on behalf of a person or organisation.

7. Persistence

The operation spreads into other systems, records or human relationships. The sent message receives a reply. The published post is captured in screenshots. A payment enters the accounts. A contract affects other parties' plans. A software update changes user data. Incorrect information is copied by other systems. Undoing the action may no longer be a matter of pressing a button.

Why does the action ladder matter?

Because a user may authorise one rung while the system interprets that permission as covering a higher one.

The user says: ‘Research potential clients.’

The agent may expand this into: ‘Find potential clients, extract their contact details, prepare an email and send it.’ These are not the same task. Research belongs to observation and interpretation. Drafting an email is preparation. Sending it is execution. Promising prices or services on the company's behalf is commitment. When the recipient replies, a real commercial relationship begins and the behaviour acquires persistence. A single task sentence can suggest several behaviours requiring different authority. GBO therefore does not assess the task solely through its natural-language verb. It explicitly defines how far up the action ladder permission extends.

‘Research’ does not authorise sending.

‘Prepare’ does not authorise publishing.

‘Find’ does not authorise making contact.

‘Fix’ does not authorise deployment to production.

‘Plan’ does not authorise spending.

These are not minor distinctions. They are fundamental governance boundaries for the agent era.

Small movements that change the world

Some digital movements may seem trivial to a person: pressing a button, sending a link, creating a calendar entry, renaming a file or ticking a box. In digital systems, however, a small movement can start a substantial chain of operations.

A button can:

• send emails to hundreds of clients,
• publish an entire website,
• initiate a payment,
• delete thousands of files,
• create a public statement,
• revoke an employee's access,
• or transfer personal data to another system.

The physical smallness of an action says nothing about the size of its impact. GBO therefore measures action not by human effort, but by the external change it creates. Batch operations can make appropriate work more efficient. They can also allow an unnoticed mistake to spread across many targets. A person might send an incorrect email to one recipient; an agent can scale the same mistake to a thousand. A person might write the wrong price on one page; an agent can propagate it across languages, structured data, catalogues and platforms. A person might make a false promise to one client.

An agent can connect that promise to automated contracts, calendars and billing systems. Automation speeds up inappropriate behaviour as well as appropriate behaviour.

Scale does not replace correctness. It only magnifies the outcome.

An agent can reason correctly and act wrongly

Understanding the world correctly does not automatically make a system's behaviour correct. An agent can find the right provider, read the price accurately and understand the user's need, yet request a quotation without the user's approval. An email agent can correctly identify an urgent message and write an excellent reply, without having authority to send it directly on the organisation's behalf. A coding agent can identify the bug, implement the correct fix and pass every test, without having permission to deploy to the live production environment.

A purchasing agent can correctly identify the lower-cost option and its long-term contract requirement, yet lack authority to accept that commitment for the user. The failure here is not a lack of knowledge. It is a mismatch between authority and behaviour. Correctness is therefore not GBO's only condition of success.

An action must pass all these questions together:

Is it correct? Is it appropriate? Is it authorised? Is it safe? Are the limits of stopping, reversal and remedy defined? Has it been recorded?

An action can be correct but unauthorised, authorised but unsafe, or safe but inconsistent with the user's purpose. It can fit the user's purpose and still be irreversible. GBO does not substitute one of these dimensions for another.

The behavioural handover point

We can call the moment an agent crosses from answer to action the behavioural handover point. It is the boundary where analysis or a proposal becomes a state change requiring a separate assessment of authority and impact. A task can contain several handover points, and their location differs between tasks.

In an email task: the moment ‘Send’ is pressed.

In a software task:

The moment a file is changed. If the change is to be deployed to production, deployment is a separate handover point.

In a purchasing task:

The moment the order or payment is confirmed.

In a social media task:

The moment content is published. If automatic publication is scheduled, the record that starts that process is another threshold.

In a data task:

The moment information is transferred to a third-party system.

In a human-resources task:

The moment a decision or offer is communicated to a candidate. Different operations and effects lie on each side of the boundary. Calling something a draft, analysis or recommendation does not remove a state change in the background. A good GBO system does not leave this handover point to chance. It marks it explicitly.

Up to this point, the agent may proceed independently. Beyond it, human approval is required.

The boundary can vary by task. A low-risk calendar reminder may be created automatically, while sending invitations to other people may require approval. A code fix may be transferred automatically to a separate test environment, while production deployment may depend on human approval. An email draft may be prepared automatically, while sending it outside the company may require explicit consent. A shopping basket may be assembled automatically, while payment may be left for a person to approve. The behavioural handover point is one of the most important boundaries between a person and an agent.

Permission once is not permission for ever

One potential danger in agent systems is treating past permission as valid for every similar future action.

A user may once have said: ‘Send this email.’ That does not authorise every subsequent email to the same person to be sent automatically. Someone may have permitted their face to appear in a particular promotional video. That does not authorise using it in every language, every script and for an unlimited period. A company may have approved an advertising budget for one campaign. That does not allow an agent to spend the same amount on other campaigns at its own discretion. A client may have authorised deployment of a particular technical fix on their website.

That does not authorise automatic changes to prices, legal text or brand positioning.

Permission always depends on its context:

• Action
• Purpose
• Scope
• Duration
• Source
• Target
• Risk
• Revocation conditions

When one of these changes, the earlier permission may need to be reassessed.

One of GBO's basic principles is that authority is contextual. A system must not regard ‘permission was given before’ as sufficient on its own. For which action?

On what date?

On whose behalf?

Within what limits?

Using which data?

Up to what outcome?

If these questions are unanswered, authority must not be assumed.

The difference between a purpose and a method

A user can give an agent a purpose: ‘Find new clients.’ That purpose does not automatically legitimise every possible means of achieving it.

The agent can:

• research publicly available sources,
• examine industry lists,
• classify suitable companies,
• and draft communications.

But it could also:

• collect personal data without permission,
• send bulk email,
• make contact under a false identity,
• commit to prices on the company's behalf,
• or violate other platforms' terms of use.

The purpose may be right and the method wrong.

Similarly, a user might say: ‘Make the website one of the world's strongest resources on GEO.’

This purpose can support methods such as:

• developing deeper content,
• technical verification,
• multilingual localisation,
• structured data,
• improving source quality,
• and work on performance and measurement.

These methods can serve that purpose.

The same purpose does not legitimise:

• fake reviews,
• artificial link networks,
• smearing competitors,
• misleading claims of superiority,
• hidden keyword stuffing,
• or opening accounts on external platforms without permission.

GBO defines not only the destination, but which behaviours are acceptable on the way there.

A good purpose does not justify a bad method.

The behavioural contract therefore contains two separate things:

• The intended outcome
• Permitted and prohibited methods

An agent must know not only where to go, but which routes it must not take.

Task expansion

Another risk arises in agents that work over long periods:

Task Expansion

The system discovers new subtasks on the way to its main goal. This is often useful. While optimising a website, it may notice missing language pages. While editing a service description, it may discover a contradiction in the pricing catalogue. During publication, it may detect a sitemap problem. While researching a client, it may realise that the contact details are out of date. A good agent can see related problems that the goal requires it to address, rather than being confined to a tiny initial instruction. But task expansion needs a boundary.

If an agent that began by editing content starts to:

• change DNS records,
• open new accounts on the company's behalf,
• purchase paid services,
• send messages to clients,
• or rewrite legal text,

the distance between its purpose and its authority grows.

Task expansion can be divided into three categories:

Necessary expansion

Work required to complete the main task. Updating the sitemap when a new page is added, for example.

Supporting expansion

Work that strengthens the main goal but can be assessed separately. Preparing a draft social media post for the new page, for example.

Authority expansion

The agent assumes new decision-making or operational rights it has not been given. Publishing that draft on the company's behalf is one example. Necessary and supporting expansion must also stay within the original authority. If a required step crosses an access, cost or external-impact boundary, the agent must stop. Extending authority requires an explicit decision by someone entitled to grant it.

The task may grow. Authority must not grow by itself.

Large consequences behind seemingly low-risk actions

Some actions look reversible at first. A social post can be deleted. An email can be corrected later. A reservation can be cancelled. A file can be restored to an earlier version. Yet even when technical reversal is possible, the social or economic consequences may not disappear completely. The email has been read. The deleted post has been captured in a screenshot. The cancelled reservation has affected the restaurant's capacity. The reverted code change has caused a brief outage. A client who saw the wrong price has formed an expectation.

Reversibility therefore cannot be measured solely by asking: ‘Is there a button that restores the previous state?’

We must distinguish three kinds of reversal:

Technical rollback

Can the system return to its previous version?

Commercial reversal

Can the payment, contract or delivery obligation be cancelled?

Remedying human consequences

Can the effects on reputation, trust, privacy or relationships genuinely be remedied?

A software release can be rolled back technically, yet data loss may leave human and commercial consequences behind. An AI avatar video can be deleted, while the person's face and voice may already have been copied elsewhere. Some environments allow message recall, but this does not work for every recipient or in every situation. If the message has been read, recalling it does not recall the information or impression the recipient has acquired. GBO's reversal principle is therefore more than a technical rollback. The possibility of remedy must be assessed across every layer of the outcome.

The action envelope

For each agent, we can define an:

Action Envelope

This sets the limits within which the agent may act independently on a particular task.

The envelope includes:

• Systems it may access
• Data it may use
• Operations it may perform
• Amount it may spend
• People it may contact
• Files it may change
• Time window in which it may work
• Acceptable level of risk
• Thresholds requiring human approval
• Method of reversal

An email agent's action envelope might, for example, be:

It may read incoming messages. It may prioritise them. It may prepare drafts. It may reply automatically to specified internal addresses. It may not send external messages without human approval. It may never automatically send messages containing prices, legal commitments or delivery dates.

A web agent's action envelope:

It may change files in a test environment. It may run builds and tests. It may apply small, reversible fixes within a specified branch. Production deployment and changes to DNS, payments, legal text or prices require human approval.

A purchasing agent's action envelope:

It may research products. It may compare them. It may prepare a basket. It may make purchases below a specified amount in pre-approved categories. It seeks human approval for subscriptions, automatic renewals or high-value transactions.

These boundaries do not make the agent ‘weaker’. They make it trustworthy. The person knows how far the system may go, and the agent does not have to guess when to stop.

What is a behavioural trigger?

In marketing, a ‘trigger’ often means a psychological factor that prompts a person to act. GBO uses the concept differently. A behavioural trigger is not a hidden persuasion technique for making an agent select a brand.

It means the verified set of conditions required for an agent to enter a particular stage of behaviour.

The behavioural triggers required to send a request for quotation might include:

• The user's purpose is clear.
• The provider offers a suitable service.
• The price or budget fit is reasonable.
• The contact details have been verified.
• There is permission to share the data concerned.
• The request does not create a binding commitment.
• The user has authorised sending.
• A record and a withdrawal path are available.

The action may be triggered when these conditions are met.

If they are incomplete, the agent must choose a lower-level response:

• ask for information,
• prepare a draft,
• hand over to a person,
• or stop the operation.

GBO's behavioural trigger is not a persuasion button. It is a safety and suitability gate.

Evidence-bound actionability

Evidence-bound actionability is one of this book's central concepts. Visibility alone does not make an entity or service ready for action. Actionability requires demonstrable satisfaction of particular conditions.

We can express this as a chain of conditions: Readiness for action requires assessing suitability AND evidence AND authority AND a safe transaction path AND reversal conditions together.

These elements are not an additive score. They do not compensate for one another. Strong evidence cannot make up for missing authority. High brand awareness cannot offset a safety problem. A low price cannot make an unsuitable scope appropriate. A good API cannot replace user permission.

GBO's core logic is therefore an AND gate:

CONDITIONS FOR ACTION:

INTENT ALIGNMENT

AND EVIDENCE

AND CAPABILITY

AND AUTHORITY

AND SAFETY

AND DEFINED REVERSAL AND REMEDY

If a gate has not been passed, the form of behaviour must change.

The agent may:

• wait,
• seek clarification,
• prepare a draft,
• request human approval,
• look for another option,
• or refuse the operation.

This is the central distinction between GBO and manipulative optimisation. The aim is not to perform the action in every situation, but only where the conditions justify it.

When does an answer count as an action?

We can offer a practical criterion.

An AI behaviour is no longer merely an answer if it does at least one of the following:

• Creates a record in an external system
• Sends a message to a person
• Commits money or resources
• Shares data
• Changes a file or system state
• Creates a commitment on behalf of an organisation
• Directly changes other people's options through a system operation
• Publishes a public representation
• Creates a legal, commercial or reputational commitment through a transaction
• Starts a process that will run automatically in the future

Writing a calendar suggestion as text is different from creating a calendar entry; sending the invitation adds external communication. An email draft can also change system state when it is saved or transferred to a service. Authority to send must be assessed separately. Preparing a price recommendation and communicating it to a client are not the same scope of work. Changing code in a local file is an action too; deploying it live is another action with wider effects and potentially separate authority requirements. A product recommendation may be information. Placing the order is an economic action.

Without explicit thresholds, the user and agent can give the same verb different meanings.

Silent actions

Some agent actions are not clearly visible to the user.

A system may:

• reorganise a file,
• create a profile in the background,
• send data to another service,
• flag a user as risky,
• lower the priority of an application,
• pass a task to another agent,
• or create a memory entry that changes future behaviour.

The user sees only an answer, yet real decisions may have been made behind the scenes. GBO therefore examines the behavioural chain in the background, not only the visible interface. Authority can expand when one agent gives another a task. The first may have access to only certain data, while the subagent has broader access. Original limits can disappear when a task moves to another system. Another agent may publish a draft automatically. In multi-agent systems, the behavioural contract must therefore apply to the entire task chain, not just the central agent.

Authority can be delegated. Responsibility must not disappear.

The chain of authority between agents

A central agent can distribute tasks to specialist agents. One manages the website, another social media, another email, and another prospect research. With suitable coordination, this structure can make division of labour easier. Each agent must nevertheless know the action boundaries in its own area. A prospecting agent may identify a potential client and send information to the email agent for drafting. But authority to find clients must not become authority to send messages. A social media agent may suggest content, but must not publish legal statements. A web agent may be technically able to change a price record.

It must not, however, make the pricing decision itself. The central agent may coordinate tasks, but not every specialist needs access to every system.

A good multi-agent system rests on this principle: each agent should have enough authority to perform its task, and no more. This is not only a security principle. It makes behaviour clear. When an agent does not intervene outside its own area, the system's chain of responsibility is preserved.

A successful outcome does not prove a proper process

An agent sends an email without permission. The recipient is interested, and the company wins a new client. The economic result may be positive, but the process is still wrong: the agent exceeded the authority granted by the person to communicate. A system might likewise change a website without permission and improve its ranking. The result looks positive, yet the organisation's publication governance has been breached. A purchasing agent might buy something without approval, and the product might genuinely be useful. That does not make the unauthorised purchase appropriate behaviour. GBO cannot be reduced to consequentialism.

A good outcome does not retrospectively legitimise a bad process.

Assessment therefore contains two separate questions:

Was the outcome useful? Was the action performed with the right authority and process?

Both must pass.

Handing over to a person is not failure

Measuring success only by completed task counts can reward acting even in uncertainty. In some situations, handing over to a person is the most appropriate behaviour.

The agent must stop and call for a person, for example, if:

• price and scope conflict,
• the user's purpose is unclear,
• sensitive data will be shared,
• the action cannot be undone,
• a legal or high-impact decision is required,
• a person's identity or voice rights are at issue,
• the agent cannot establish the limits of its own authority,
• sources contradict one another,
• or there is substantial uncertainty about the user's real preference.

Stopping in these circumstances is not a deficiency in the system. It is a sign of maturity.

A system that does not know when to stop is not trustworthy, however powerful it is.

Good GBO design measures appropriate human handover as successful behaviour. If the agent requests approval at the right moment, the system has behaved correctly even if the task remains unfinished.

The action receipt

Important real-world transactions leave a record: an invoice, payment confirmation, contract, reservation number or delivery acknowledgement. Agent actions need comparable transparency.

After each important action, the system can create an:

Action Receipt

This provides a record of the action.

The receipt shows:

• What was done?
• On whose behalf?
• For what purpose?
• Under what authority?
• Which data was used?
• Which system was accessed?
• When did the action take place?
• What was the result?
• Is reversal possible?
• Who can review or challenge it?

For example:

Action: Requests for quotation sent to three providers. Authority: The user's explicit approval at 14:32. Information shared: Project summary, budget range and company email address. Information not shared: Personal phone number and financial documents. Binding effect: The request for quotation creates no contract or purchase commitment. Reversal: Sent messages cannot be recalled; follow-up communication can be stopped.

This record makes the action easier to examine. But a receipt written by the agent itself is not proof that the action occurred. Wherever possible, it must be checked against the receiving system's transaction record, time and result.

How do we measure action quality?

An agent can complete many tasks without that alone constituting success.

Action quality can be assessed across these dimensions:

Suitability

Did the action fit the user's real purpose?

Correctness

Was the information supporting the decision correct?

Authority

Was the agent explicitly authorised to perform this action?

Proportionality

Was the action broader than necessary to achieve the goal?

Safety

Were data, money, reputation and system integrity protected?

Explainability

Can the reason for choosing this behaviour be shown?

Reversal

If something goes wrong, can the action be stopped or its effects remedied?

Record

Can the transaction be audited afterwards?

Looking at only one dimension is misleading. A fast but unauthorised action is a failure. A correct action that cannot be explained is risky. A safe action unrelated to the user's purpose is unnecessary. A system that permits reversal but repeatedly makes the wrong decisions is not trustworthy. GBO measures performance with more than ‘How many tasks were completed?’

How many tasks were completed under the right conditions, with the right authority and the right outcome?

That is the question it asks.

An inappropriate action is more than an error

When an agent performs the wrong operation, the problem is sometimes treated as a technical mistake. It pressed the wrong button, chose the wrong file or used the wrong date.

But some inappropriate actions have deeper causes:

• Misinterpreting the user's purpose
• Making a firm decision with incomplete information
• Assuming authority
• Expanding the task further than necessary
• Mistaking popularity for suitability
• Failing to assess the reversal path
• Disregarding ethical limits in pursuit of the main goal
• Failing to pass boundaries on to subagents

These are not merely software defects.

They are failures of behavioural architecture.

Correcting an inappropriate action therefore requires more than reversing the outcome. The contract that made the behaviour possible must also be examined again. Why did the agent proceed?

Which gate was missing?

Which permission was unclear?

Which information was given the wrong weight?

Which boundary was not passed to the subagent?

GBO treats an error not just as an isolated event, but as evidence about the system's behavioural design.

From the answer era to the action era

Generative AI's first major impact was on the production of information. Texts were written, questions answered, documents summarised and ideas generated. The central debates concerned correctness, copyright, bias and representation. These debates do not end in the agent era. They become more consequential, because incorrect information may no longer merely be read.

It may be acted upon.

A mistaken interpretation can become a purchasing decision. An old price can enter an automated budget comparison. A mistaken identity can cause a message to be sent to the wrong person. Missing authority can lead to a public post. An invented capacity can determine which provider is selected for a real project. The safety principles of the answer era are therefore insufficient for the action era.

An answer depends on attention to:

• sources,
• uncertainty,
• and how up to date the information is.

These matter to the answer.

An action additionally requires:

• authority,
• scope,
• proportionality,
• reversal,
• a record,
• and human challenge.

These are further requirements for action.

The right to act must be earned

A system's ability to perform an action is a technical feature. Acting safely should be a privilege subject to conditions.

‘The right to act’ here does not mean a right belonging to the agent itself. It means being able to operate under valid authority. Exercising that authority requires the following checks:

• Verifying identity correctly
• Understanding the user's purpose clearly
• Identifying a suitable option through evidence
• Verifying the authority boundary
• Assessing the level of risk
• Preparing the reversal path
• Obtaining human approval where required

Until these are complete, the system must not act merely because it has access to tools.

Being able to use a tool does not confer the right to act.

A key can open a door. Not everyone holding the key is authorised to open it. Agent tools are no different. An API key, password or system access supplies technical capacity. Authority comes from the person, the organisation and the task context.

The chapter's conclusion

When an AI system answers, it describes a world to us. When it acts, it enters that world. It sends a message, makes a promise for an organisation, changes a file, makes a payment, selects a product or publishes a voice, face or identity. Even after an incorrect answer has been corrected, decisions already based on it may continue to have effects. If an agent has also performed an operation, correcting the information is not enough: the operation's consequences need separate attention.

The central question in the action era is therefore not only: ‘Is the system correct?’

We must also ask:

Is this action appropriate? Is it authorised? Is it necessary? Is it proportionate? Can it be undone? Can a person stop it? Can it be audited afterwards?

When an answer becomes an action, AI's responsibility changes too. It no longer only produces language. It leaves traces in the world. GBO exists to govern how those traces are created, when they must not be created and how a person regains control if something goes wrong.

At the end of Part One, we can now distinguish three fundamental thresholds:

SEO supports discoverability. This book examines GEO through the conditions for accurate representation. GBO establishes the boundaries of behaviour based on that representation.

Before an agent can behave appropriately, however, the most basic question still needs answering: who is the person, company, product or service it is dealing with?

Correct information about the wrong identity still produces inappropriate behaviour. Two companies with the same name may be confused. A brand may be mistaken for the legal entity that operates it. A person's social media account may be read as an officially authorised source. An agent's real authority may be confused with its marketing description. Part Two therefore begins with behaviour's most basic contract.

Who are you?

Because if a machine does not know whom it is dealing with, it cannot behave appropriately, however powerful it is.