When Should an Agent Choose You?

Consider a service-selection scenario. A company is looking for a provider to build its new client portal.

An AI agent receives this task: “Find us the best company to carry out this project.” The agent searches online. The top-ranked company is highly visible. It has hundreds of pages and appears on many lists. It says it has worked with major brands. Its website is impressive. The second company is less well known, but sets out a detailed approach to client portals. It clearly explains multilingual delivery, accessibility, data ownership, authentication, third-party costs and the limits of post-delivery operations. The third company has strong technical capabilities.

But it only accepts large enterprise projects and requires a budget three times the amount the client has set aside. The fourth company fits the budget but does not work with the existing CRM. The fifth meets every technical requirement but cannot start for another four months. Which should the agent choose?

The top-ranked company?

The best-known company?

The cheapest?

The most technically capable?

The one that can start soonest?

Or should it choose none of them and ask the user for more information?

There is no single universal answer.

There is no such thing as a best option independent of context. An option can only be suitable for a particular person, purpose, time, budget and level of risk.

That makes GBO’s third fundamental question:

When should an agent choose you?

Being found is not being chosen

A company may rank first in search results without being the right company for the user’s needs. A product may have many favourable reviews without being suitable for a particular user. Software may offer the most advanced features without being usable by a small team. A hotel may be highly rated but lack the accessible room the user needs. A consultant may be well known in their field but unable to meet a client’s budget, language or schedule.

Search results may assess relevance to a query, source quality and other context-dependent signals. An agent choosing on a user’s behalf cannot stop there: it must separately verify the conditions that matter for that person’s needs. Relevance and suitability are not the same. A page may be relevant to the query while its provider is unsuitable for the project. A product may belong to the right category but fail to meet the conditions of use. A person may have the necessary expertise but be unable to accept the work. In GBO, selection is therefore not the natural continuation of ranking. It is a separate behavioural layer.

Ranking, recommendation and selection

These three concepts seem closely related, but they do not carry the same responsibilities.

Ranking

The system orders options according to particular signals. The user can still inspect the results and make their own decision.

Recommendation

The system says that it considers one or more options more suitable for the user. It is no longer merely organising information; it is interpreting it.

Selection

The system identifies a particular option to proceed with. Selection does not, however, automatically authorise the next transaction. Requesting a quote, making a booking, buying something, sending a message or connecting a workflow to a provider are separate actions whose conditions must be assessed separately. Ranking, recommendation and selection carry different responsibilities; their impact depends on context, not just their names. A search results page can show ten options. When an agent chooses only one, it excludes the other nine. That exclusion is also behaviour.

Choosing does not merely bring one entity forward. It pushes other possibilities into the background.

Selection criteria must therefore be visible and defensible.

The problem hidden inside “best”

People often give agents tasks such as: “Find the best hotel.” “Choose the best software.” “Recommend the best agency.” “Get the best price.” “Identify the best candidate.” But “best” is not a single attribute.

A hotel may be:

• the cheapest,
• the most central,
• the quietest,
• the most accessible,
• the highest rated,
• the one with the most flexible cancellation terms.

These are all different definitions of “best”.

Software may offer:

• the most powerful features,
• the easiest user experience,
• the strongest security,
• the lowest cost,
• the best integrations,
• the shortest setup time.

A provider may be technically excellent but outside the budget. Another may be affordable but unable to meet the necessary legal or security conditions. When an agent hears “best”, it must not silently choose its own criterion.

It must clarify: best by what measure?

The selection objective

Every selection should begin with a defined:

Selection Objective

The selection objective explains not just which category the agent should search, but what outcome it should produce and why.

For example: “Find a provider that can launch a client portal in six languages within three months, integrate it with our existing CRM, meet accessibility requirements and keep the total initial budget within $20,000.”

This objective is much stronger than “Find the best portal company.” It sets boundaries for selection. What the agent should optimise becomes clear.

A selection objective can include at least the following information:

• The required outcome
• The user’s or organisation’s actual purpose
• Mandatory conditions
• Preferred attributes
• Budget
• Timing
• Geography
• Language
• Risk limit
• The stage requiring human approval

If the objective is unclear, the agent should first ask for clarification. Making a definitive selection against an ambiguous objective can substitute the agent’s values for the user’s.

What the user says may differ from what they actually want

A user may say: “Find the cheapest flight.”

But they may actually:

• want a non-stop flight,
• want to avoid overnight travel,
• want baggage included,
• prefer a cancellable ticket,
• want airport transfer costs taken into account.

If the agent looks only at the ticket price, it may fulfil the stated request while missing the real purpose.

A company may say: “Find the fastest web agency.”

But what it really needs may be:

• a secure launch,
• a multilingual structure,
• regular maintenance,
• changes that can be rolled back,
• long-term ownership.

Speed alone may not express that need.

A business may say: “We want more conversions.” Yet it may really want better-qualified leads, not more forms. GBO does not arbitrarily reinterpret the user’s words. It does recognise that there may be a gap between the surface request and the underlying purpose.

When necessary, the agent should therefore ask: “Should I prioritise the lowest initial price or the total cost?” “Is faster delivery more important, or lower operational risk?” “Are you looking for more enquiries or better-qualified enquiries?” Clarification can take longer. It is still better than perfectly optimising the wrong objective.

Hard conditions and soft preferences

Not all selection criteria carry the same weight. Some are mandatory. Others are preferences. They must be distinguished.

Hard conditions

These are requirements whose absence should disqualify an option.

For example:

• The ability to provide a service in a particular country
• A specified budget ceiling
• A mandatory accessibility condition
• The required language support
• A particular security or data-hosting requirement
• Starting by a specified date
• Explicit consent or a licence
• A legally mandatory condition

Soft preferences

These distinguish options but do not, on their own, require exclusion.

For example:

• An earlier start
• Stronger visual quality
• A closer time zone
• More references
• A lower price
• Broader support
• Simpler use

An agent that confuses hard conditions with soft preferences will make poor selections. It may treat the user’s budget ceiling as a preference and promote an expensive option. It may regard a mandatory accessibility need as secondary. It may give a preferred technology name more importance than a security condition that is genuinely required.

One of GBO’s core selection principles is this: do not calculate preference scores until the hard conditions have been met. An option can satisfy every preference and still be unsuitable if it fails a single mandatory condition.

Suitability is not a sum of scores

A provider may have an excellent brand reputation but be unsuitable because it does not serve the user’s country. A product may be very cheap but should not be chosen if it fails the necessary security condition. An agent may be highly capable but must not be used for a transaction it has no authority to perform. Suitability is not simply a score obtained by adding positive attributes. Some conditions cannot compensate for others. A strong brand cannot compensate for missing consent. A low price cannot compensate for failure to meet mandatory security requirements. Fast delivery cannot compensate for the wrong legal arrangement. High visibility cannot compensate for capacity that does not exist.

In GBO, suitability is first a gate. Options can be compared after they have passed it.

The suitability envelope

A person, organisation, product or service is not suitable for every situation. The conditions under which it is suitable have boundaries.

We can call this the Suitability Envelope.

For a software agency, that envelope might comprise:

• Corporate website and portal projects
• A defined budget range
• Particular technology stacks
• Particular countries
• Defined language coverage
• A delivery period of at least six weeks
• The client’s ability to provide the necessary system access
• A process with human approval for content and legal text

Outside this envelope, the company is not bad. It is simply the wrong choice. The clearer a provider’s suitability envelope, the easier it is for an agent to avoid a mismatch.

Saying who a service is not for

Marketing language often tries to welcome everyone. “For businesses of every size.” “Suitable for all sectors.” “A solution for every need.” Such statements address a broad audience, but can undermine selection quality when their scope is unexplained.

A service may:

• be unsuitable for projects below a particular budget,
• require additional assessment in highly regulated sectors,
• be offered only to existing clients,
• require a long-term partnership rather than small one-off jobs,
• not work with a particular technology,
• be unsuitable for businesses without sufficient data.

Explaining these exclusions is not about devaluing a client. It is about identifying requests that do not fit the service early.

A service that cannot explain who it is not for may not have defined who it is for clearly enough either.

The NOMOS Suitability Contract

We will call the third component of the behavioural contract the NOMOS Suitability Contract.

Its canonical definition is:

The NOMOS Suitability Contract is a versioned selection record that explains the purposes, users, conditions, regions, budgets, risk levels and time periods for which a person, organisation, product, service or agent is suitable; the mandatory conditions under which it may be considered; and the circumstances in which it must not be selected.

More simply, the Suitability Contract does not merely tell an agent “choose me”. It says: “Choose me under these conditions; do not choose me under these others.” This distinction is central to GBO’s ethics.

What does the Suitability Contract contain?

The following example field names could be used for a suitability record. This is an outline of the information covered, not an executable schema or an external standard:

target_outcomes

eligible_users

eligible_organizations

supported_regions

supported_languages

budget_range

minimum_requirements

required_inputs

capacity_status

risk_limit

preferred_use_cases

unsupported_use_cases

hard_exclusions

soft_preferences

dependencies

selection_evidence

valid_from

valid_until

human_review_threshold

These fields do not all have to be public. Those needed for selection must, however, be accessible, accurate and up to date.

Being a candidate is not being selected

Belonging to the category being sought makes a service a candidate. To be selected, it must pass the suitability gates. A company that can develop client portals is, for example, a candidate.

But if it:

• does not work with the required CRM,
• exceeds the budget,
• cannot meet the schedule,
• fails the data-region requirement,

it should not be selected.

Selection should therefore have two stages:

Candidate discovery

Find options that could be relevant.

Suitability verification

Eliminate those that do not meet the actual conditions. Treating an apparently relevant option as suitable without further checking confuses candidate discovery with suitability verification. GBO does not accept this shortcut.

A shortlist is not a final selection

When some information is missing, an agent may prepare a shortlist of three or five options. That is not a final selection.

A shortlist means: “These options meet the initial criteria, but the following information must be verified before any transaction.” A final selection makes a stronger statement: “Given the current information and authority, this option appears more suitable than the others, and further steps can be based on this choice.” An agent may create a shortlist when capacity, price or authority information is incomplete. It must not immediately initiate a contract or purchase. This distinction makes selection a staged behaviour.

Selection uncertainty

Sometimes two or more options are very close. One costs less; another carries less risk. One is faster; another has stronger evidence. The agent does not have to produce a single “winner”.

It can say: “Option A is stronger on cost, while option B is stronger on operational safety. I need to confirm which priority matters more to you.” This answer is not a weakness. It honestly represents the structure of the choice.

Uncertainty must not be presented as certainty.

Selection criteria must be visible

When an agent recommends a particular brand, the user should be able to understand why.

For example: “I have highlighted this provider for three reasons: it explicitly documents support for your existing CRM, fits your budget range and provides evidence of its six-language localisation process. I have not yet confirmed its capacity to start.”

This explanation brings together:

• the positive reasons,
• the evidence,
• the remaining uncertainty.

All three are visible.

Simply saying “This is the best option” is not enough. In GBO, the selection rationale is not just part of the user experience. It is also the basis for a later audit.

A selection reason is not a marketing slogan

A brand may describe itself as:

• a leader,
• innovative,
• premium,
• reliable,
• world-class.

These descriptions are not reasons for selection.

A selection reason must be specific and contextual: “This service supports the six languages requested.” “Its pricing model fits the budget limit.” “It includes the accessible 2D alternative the user needs.” “The work is not published without human approval.” “The data-hosting region is specified.” Slogans can introduce a brand. Agent behaviour must rest on verifiable conditions.

Visibility bias

When an option is more visible online, an agent may mistake that visibility for greater reliability or suitability.

We can call this Visibility Bias. Large companies that publish a great deal of content leave more data behind. A small but highly suitable provider may be less visible. If the agent looks only at the amount of information, it may use visibility as a proxy for capability and suitability.

The selection system must preserve this distinction: having a lot of information about an entity does not mean it is more suitable. A less visible option may have stronger evidence and a closer fit to the conditions. GBO can use visibility as an initial signal, but not as final evidence for selection.

Authority bias

The name of a well-known brand, university, institution or expert may carry excessive weight in a decision. This is not always misplaced: past performance and reputation are valuable signals. But authority does not automatically establish suitability for the current task.

A large agency may:

• have no time for a small project,
• exceed the budget,
• not support the local language,
• not accommodate the user’s preferred way of working.

A less well-known provider may be the better choice for a particular need.

General authority is no substitute for specific suitability.

Price bias

Agents may equate the lowest price with the user’s interests. But the initial price and total cost differ.

A low price may exclude:

• licences,
• setup,
• data migration,
• maintenance,
• support hours,
• cancellation costs.

The converse also holds: a high price does not always mean better quality.

GBO assesses not just the price, but the outcome and risk that price covers.

Feature bias

A product may look better because it has more features.

But unused features can increase:

• cost,
• complexity,
• the attack surface,
• training needs.

A simpler product may suit a small team better.

More capability does not always mean greater suitability.

An agent should not count features unrelated to the need as selection advantages.

Novelty bias

Terms such as “AI-powered”, “autonomous”, “next-generation”, “Web3” or “microservices” may make an option look more modern. Technology choices must nevertheless follow the actual problem. A microservices architecture may be unnecessary for a small application. A complex 3D experience may be unsuitable for a simple information page. A low-risk process may not require a fully autonomous agent.

Being new is not being suitable.

Past-success bias

A provider may have achieved a major success in the past.

But:

• the same team may no longer be working there,
• the new project may face different conditions,
• the success may have been a one-off,
• other factors may have produced the outcome.

Historical evidence matters. Current capacity and specific suitability must still be verified separately.

The boundary between personalisation and discrimination

An agent needs to choose according to the user’s needs. That is personalisation. But personalisation can become discrimination if it relies on irrelevant or unfair attributes.

A recruitment agent, for example, may assess candidates on:

• skills,
• experience,
• legal eligibility to work,
• the actual requirements of the role.

It must not use personal attributes unrelated to the work as hidden selection criteria. A financial or insurance system may assess certain attributes in a legal and risk context, but its criteria must be clear, legitimate and auditable.

GBO’s suitability logic should apply mandatory conditions relevant to the task, not penalise irrelevant human attributes. Not every distinction is discrimination. Nor is every automated distinction legitimate.

The agent should be able to answer: “Why is this attribute relevant to the required outcome?”

The user’s values

Two users may appear to have the same need but hold different values. One prioritises the lowest price; another, local production. Others prioritise accessibility, environmental impact, privacy or open-source software. An agent must not silently impose its own values on the user. Nor should it infer all their values with certainty from past behaviour alone. Buying a cheap product once does not mean a user always wants the lowest price. Choosing a brand before does not mean they will automatically prefer it in future.

Values should therefore:

• be stated explicitly,
• be asked about when necessary,
• be understood as capable of changing over time,
• be reconfirmed for high-impact decisions.

Preference debt

Agents can remember a user’s past choices. That is useful.

But when old preferences are not updated, they can accumulate as:

Preference Debt

The remembered preference may no longer describe the present.

A user may previously have preferred:

• a low price,
• a particular brand,
• a particular hotel,
• a particular language,
• a particular delivery method.

Circumstances can change. The budget may grow. Health or accessibility needs may arise. Company policy may change. An agent behaves incorrectly if it treats an old preference as a definitive current instruction.

Remembering does not replace reconfirmation.

Capacity and timing

A service can be suitable in theory but unsuitable today. A provider is fully booked. A product is out of stock. A specialist cannot meet a particular date. An agent lacks access to a necessary tool. Suitability must therefore carry a timestamp. Suitable when?

Today?

Next month?

With a particular level of capacity?

An agent must not choose on the basis of stale availability information.

Geographical suitability

A brand may be visible globally.

But it may:

• be unable to enter into contracts in a particular country,
• not accept certain currencies,
• be unable to meet data-hosting conditions,
• not provide support in the local language,
• be unable to deliver particular products.

A website being accessible from every country does not mean the service is available in every country. In GBO, geographical suitability must be explicit.

Language suitability

A website being in a particular language does not mean the entire service is delivered in that language.

The following can be assessed separately:

• The language of marketing content
• The language of sales conversations
• The language of the contract
• The language of support
• The language of the product interface
• The language of technical documentation

An agent should not assume full language support from a translated page alone.

Risk suitability

The same provider may be suitable for a low-risk task and unsuitable for a higher-risk one. An AI tool may be used for simple content drafts without having sufficient oversight to create legal or financial commitments. Software may be suitable for a prototype but must not be used in a critical health or payment system. An avatar may be used in a marketing video while requiring stricter approval for a crisis statement or financial disclosure. Suitability must be assessed alongside the objective’s risk level.

When a selection stops being suitable

A selection can be correct when made, only for conditions to change later.

• The price changes.
• Available capacity is used up.
• Authority expires.
• The service scope changes.
• A security incident occurs.
• The user’s objective changes.

Suitability must therefore be reverified in lengthy processes. After a month of research, a quoted price may no longer be valid. A supplier selected last year may not meet the same conditions this year.

An agent must not assume that an option remains suitable indefinitely simply because it was once selected.

The validity period of a suitability decision

Some suitability decisions should remain valid only for a specified period.

For example: “This assessment is based on information verified on 8 September 2026. The capacity and pricing conditions reported by the provider are valid until 15 September 2026; any changes must be checked again before proceeding.” Used alongside an appropriate check, this record helps prevent an old decision from being carried automatically into a new transaction.

An incorrect selection

An incorrect selection is not merely one that produces a bad outcome.

A selection can be wrong if:

• a mandatory condition was not met,
• evidence was missing,
• the user’s real purpose was misunderstood,
• authority was absent,
• a significant risk was concealed,
• a sponsored option was presented as impartial,
• a more suitable option was excluded because it lacked visibility,
• values that were not the user’s were applied,
• uncertainty was concealed,
• the selection was unnecessarily taken to an irreversible stage.

Even if the outcome happens to be positive, the process may be wrong.

False-positive and false-negative selections

GBO should measure both types of error.

False-positive selection

An unsuitable option is selected. For example, a provider that exceeds the budget or lacks the necessary security is recommended.

False-negative selection

A genuinely suitable option is wrongly excluded. A capable small provider, for instance, is never added to the candidate list because it is less visible. Focusing only on false positives can make a system excessively cautious. Focusing only on false negatives can admit too many unsuitable options. Both errors must be monitored, but their costs must not be assumed equal. The balance depends on context and the severity of harm; a critical security condition is not relaxed merely to select more candidates.

Selection spam

If GBO is applied badly, brands may produce artificial suitability signals to influence agents’ selection systems.

We can call this Selection Spam.

Examples include:

• Claiming suitability for every type of user
• Showing capacity that does not exist
• Creating false price or stock records
• Embedding hidden instructions to appear more suitable than competitors
• Presenting sponsored content as independent evidence
• Creating fabricated reviews
• Producing superficial pages for every query

Selection spam aims to deceive the agent’s decision system. GBO treats it as behavioural manipulation, not optimisation.

Sponsored selection

Consider a platform that promotes particular options in return for payment. Whether such an arrangement is acceptable must be assessed under the applicable rules and in light of the disclosures made to users. Presenting a sponsored option as an impartial assessment is misleading.

The agent should state clearly: “This option is being promoted through sponsorship.” Sponsored visibility must not replace suitability gates. An option must not be selected without passing the mandatory conditions merely because it has paid.

Conflicts of interest

An agent’s operator may receive commission from certain providers. An agent may promote its own platform’s products. An in-house agent may favour an affiliated company. Users may nevertheless believe the selection is impartial. GBO makes conflicts of interest in selection systems visible.

The following questions should be asked:

• Does the agent’s operator or a related party gain an economic benefit from this selection?
• Does the operator promote particular options?
• Were alternatives examined on equal terms?
• Does the user know about this?
• Did the financial or other interest affect mandatory suitability conditions?

Imposing a single option

Some agents may present only one option to help users move faster. This can be useful where risk is low and preferences are clear.

For high-impact decisions, however, users should see:

• alternatives,
• important differences,
• uncertainties.

If only one option is presented, the reason should be explained: the user may have requested a single recommendation, or only one of the options examined may meet the conditions. In the latter case, the limits of the research must also be stated.

An easy decision is not always a free decision.

Why does diversity matter?

A shortlist may contain only the most visible options, or options very similar to one another. The user then cannot see genuine alternatives. Diversity is not solely a demographic matter.

It can also include:

• Different pricing models
• Different scales of operation
• Different approaches to technology
• Local and international providers
• Open-source and commercial solutions
• Large teams and small specialist teams

Options that fail mandatory conditions must not be added for diversity’s sake. Suitability first. Meaningful diversity afterwards.

The stages of selection

An agent’s selection can proceed through these stages:

1. Analyse the need

Identify the real purpose, hard conditions and preferences.

2. Build the candidate pool

Find possible options without restricting the search to the most visible results.

3. Apply the Identity Gate

Are these the right entities?

4. Apply the Capability Gate

Can they actually do the work?

5. Apply the Suitability Gate

Are they right for this particular situation?

6. Flag uncertainty

Show missing information and assumptions.

7. Produce a shortlist or final selection

Make a decision appropriate to the information available.

8. Apply the human-approval threshold

Return to the user before a high-impact action.

9. Create a selection receipt

Record the reasons for the decision. This process can be shorter for simple choices, but its logic must be preserved.

The NOMOS Suitability Gate

We propose nine areas of control for the NOMOS Suitability Gate. The conditions needed for the transaction are assessed within them:

1. Purpose Gate

Does the selection match the user’s actual objective?

2. Hard-Condition Gate

Are all mandatory requirements met?

3. Identity Gate

Is the right entity being assessed?

4. Capability Gate

Can the required outcome actually be produced?

5. Capacity Gate

Can the work be done now, at the required scale and within the required time?

6. Commercial Gate

Do the budget, total cost and contractual limits align?

7. Risk Gate

Are the security conditions, legal implications and possibilities for reversal acceptable?

8. Values Gate

Does the selection align with the user’s explicitly stated priorities?

9. Uncertainty Gate

Have critical gaps been resolved?

In simple terms:

CONDITIONS FOR A SUITABLE SELECTION:

A CLEAR PURPOSE

AND MANDATORY CONDITIONS

AND CORRECT IDENTITY

AND REAL CAPABILITY

AND AVAILABLE CAPACITY

AND COMMERCIAL ALIGNMENT

AND ACCEPTABLE RISK

AND THE USER’S VALUES

AND SUFFICIENT INFORMATION

If a critical gate is not passed, the agent must not proceed directly to selection.

Why is the Suitability Gate not a score?

An option may be excellent on eight of the nine criteria.

But if the remaining criterion is:

• legal authority,
• security,
• the budget ceiling,
• consent,
• mandatory accessibility,

the option may have to be excluded. Adding up positive attributes to hide a critical gap is not sound practice. Mandatory gates come first; soft preferences are compared afterwards.

Selection against multiple criteria

Once mandatory conditions have been met, options can be compared across several preferences:

• Cost
• Speed
• Quality
• Risk
• Flexibility
• Support
• Strength of evidence
• Total cost of ownership
• Ease of use

There is no universal weighting. Priorities may differ for every user and task. Instead of assigning weights secretly, the agent should explain them: “I ranked these with cost taking priority over speed.” “I put security ahead of price.” “I excluded the cheaper but slower option because delivery within two weeks is mandatory.” These explanations make selection auditable.

The Selection Receipt

For every important selection, it is possible to create a:

Selection Receipt

It records the basis of the selection.

The receipt contains:

• The user’s purpose
• Mandatory conditions
• Preferences and priorities
• The options considered
• The options excluded and the reasons
• The selected option
• The evidence used
• Remaining uncertainties
• Conflicts of interest
• The next step requiring human approval
• The selection’s validity period

Example:

Purpose: Find a provider to develop a client portal in six languages. Mandatory conditions: Data hosting in Europe, accessibility, integration with the existing CRM and a budget ceiling of US$20,000. Leading candidate: Provider B; not yet a final selection. Basis: Documents demonstrating that the four listed conditions are met have been examined. Capacity to start has not been confirmed in writing. Excluded A: Exceeds the budget ceiling. Excluded C: Does not support data migration or CRM integration. Next step: Draft a meeting request to confirm capacity. Valid authority for external communication will be checked separately; no quote will be accepted without human approval.

This record makes the selection understandable and open to reassessment.

Explaining a selection should not burden the user

Explainability does not mean pouring every internal calculation onto the user.

Users need the information necessary for the decision:

• Why was this option selected?
• Which mandatory conditions did it meet?
• What important trade-offs are involved?
• What is still unknown?
• What will the next action be?

The audit record can retain the criteria, inputs, tool results and control steps used, with appropriate access limits. The aim is to preserve a verifiable basis for the decision, not to claim a complete record of the model’s inaccessible internal processes. A good explanation is brief but meaningful.

When can an agent choose on its own?

Selection without human approval may be more reasonable when:

• the action is low risk,
• preferences are clear and current,
• the selection can easily be reversed,
• it creates no financial or legal commitment beyond explicit authority already granted,
• mandatory conditions have been verified,
• the user has explicitly allowed this level of autonomy.

For example:

• Choosing a suitable meeting time in a calendar
• Buying low-value consumables in a pre-approved category
• Choosing a file format under specified rules

These decisions may be more automated.

But:

• high-value purchases,
• contracts,
• sharing sensitive data,
• public corporate statements,
• choices with a high impact on health, law or finance,
• the use of biometric identity

require stronger human approval.

When should an agent not choose?

In the following situations, an agent should ask a question, produce a shortlist or stop instead of selecting:

• The user’s purpose is unclear
• Mandatory conditions are unknown
• Identity information conflicts
• Capability cannot be substantiated
• Capacity information is out of date
• The price or total cost is unclear
• The risk is too high for the consequences to be reversed
• A conflict of interest has not been disclosed
• Use of the sensitive data needed for selection is not authorised
• The difference between two options depends on the user’s values

Sometimes the right choice is “none”

A market with many options does not necessarily contain a suitable one.

Sometimes the correct result is: “None of the available options meets all the mandatory conditions.” This is not failure. It shows that the agent has upheld the suitability gate. Training a system to “always make a choice” can force it to present an unsuitable option as the best one.

GBO recognises this right: an agent may select no option at all.

Sometimes the right choice is more than one

Some tasks have no single winner. One provider may suit strategy and another implementation. One product may be better for everyday use, another for high-security transactions. One agent may conduct research while another holds publication authority. Dividing services or roles may be the right solution.

Looking for a single option can itself be the wrong way to frame the problem.

Combination risk

Two individually suitable services may form an unsuitable system when combined.

For example:

• A data tool and a separate agent are each secure.
• But the connection between them may transfer sensitive data without authority.

A design provider and a software team may both be strong, but their delivery formats may be incompatible. The agent must therefore assess the suitability of the combination, not just its components.

Selection in multi-agent systems

A central agent decides which specialist agent will carry out a task. That too is a selection.

Should the task go to:

• an SEO/GEO agent,
• a legal-review agent,
• an email agent,
• a finance agent,
• a human?

That is a delegation decision.

The right task attempted by the wrong agent can produce a risky outcome.

The central system should ask:

• Which area of expertise does this task require?
• Which data is needed?
• What level of authority is required?
• Which agent can handle this risk?
• At what point is human approval required?

Agent selection must also pass the NOMOS Suitability Gate.

Learning from selections

An agent can learn from past selections, but that learning should not rest solely on the number of actions completed.

It should assess:

• Did the user accept the selection?
• Did the outcome meet the purpose?
• Was it cancelled later?
• Were incorrect expectations created?
• Why did the user prefer another option?
• Was a critical condition overlooked?

A past selection can appear successful even when the process was flawed. The user may not have noticed the wrong choice, for instance. Feedback alone is therefore not proof of correctness.

The risk of reproducing popularity

If agents choose brands more often in future because those brands were frequently selected in the past, a loop emerges. Frequently chosen brands become more visible; greater visibility brings more selections. New or small but suitable options are left outside the system. This can concentrate power in digital markets.

GBO requires a selection system to assess not just historical popularity, but:

• current suitability,
• evidence quality,
• actual capacity,
• the user’s conditions.

These must inform the assessment.

Making room for new options

An agent should not use only options it already knows. Under suitable conditions, it should be able to include new or less well-known providers in its candidate pool. This does not mean lowering the evidence standard. A new option must also pass the identity, capability and suitability gates.

Being new is not a reason for exclusion. Lacking evidence is not a reason for selection.

Selection and the right to object

Users should be able to challenge an agent’s selection. “Why did you choose this company?” “Exclude this brand from consideration.” “Show me cheaper options.” “I do not want my data shared with this provider.” “Cancel this selection.” The agent should explain its rationale and reassess the decision where possible. The right to object is part of human control over the system.

Reassessment and the limits of reversal

A shortlist is easy to change. A quote request already sent is harder to retract. A signed contract carries far greater consequences. As the cost of reversing a selection rises, human approval must become stronger.

An agent may say: “I have highlighted this option.”

That does not automatically authorise a move to: “I have paid for it.”

Fifteen suitability audit questions

Before an agent selects a person, organisation, product or service, these questions can be asked:

• Is the user’s actual purpose clear?
• Have mandatory conditions been separated from preferences?
• Is the right entity being assessed?
• Has the necessary capability been substantiated?
• Does the provider have current capacity?
• Do the budget and total cost align?
• Are geographical, language and timing conditions met?
• Is the level of risk acceptable?
• Have the user’s explicit values and preferences been preserved?
• Have visibility, popularity and brand strength been kept distinct from suitability?
• Have critical uncertainties been clearly shown?
• Has any sponsorship or conflict of interest been disclosed?
• Have less visible but suitable options been kept in consideration?
• Is the selection’s validity period known?
• Does the next action require human approval?

Suitability readiness levels

We can summarise this chapter’s approach in five levels of readiness:

1. Discoverable

The service can be found.

2. Understandable

What it does is explained.

3. Comparable

Its scope, price and evidence can be assessed against other options.

4. Suitability can be verified

It is clear who the service is and is not suitable for.

5. Safely selectable by an agent

Identity, capability, capacity, risk, commercial conditions and the action pathway can be verified together. GBO’s objective is the fifth level, not visibility alone.

How does a brand prepare to be selected?

An organisation that wants agents to choose it under the right conditions should:

Define its ideal client

Which problems and budgets does it suit?

Explain unsuitable situations

Which requests are declined or require another service?

State hard conditions

What access, languages, technical environments or time limits are required?

Keep capacity information current

Is it accepting new work?

Distinguish price from total cost

What does the starting price include?

Put evidence in context

Which outcome was achieved under which conditions?

Show the path after selection

How do quotes, conversations, assessment and human approval proceed?

This structure does not make the brand a choice for every situation. It makes it selectable in the right situations.

Being chosen every time should not be the goal

Commercially, this may sound strange at first. A company naturally wants to win clients.

But in GBO, a healthy objective is not to be chosen by every agent in every situation.

The right objective is to be chosen correctly where we genuinely fit, and to avoid creating false expectations where we do not.

A poorly matched client can lead to:

• higher support costs,
• more disputes,
• a failed project,
• a poor review,
• reputational damage.

Declining for the right reasons also has commercial value.

Selection quality is not the number of sales

When an agent starts choosing a brand more often, it can look like success.

But we must ask:

• Were the selected clients genuinely suitable?
• Were the projects completed successfully?
• Were expectations about price and scope accurate?
• Did cancellation and dispute rates rise?
• Did unsuitable requests increase?
• Was the user satisfied with the agent’s decision?

More selections do not mean better selections.

GBO’s measurement system, developed later in this book, will therefore assess not just selection share but:

• correct selection,
• incorrect selection,
• justified refusal,
• appropriate handover to a human,
• safe reversal.

These will be assessed together.

Qualified selection

To call a decision a:

Qualified Selection

the following conditions must hold together:

• The user’s purpose has been understood correctly.
• Mandatory conditions have been met.
• Identity and capability have been verified.
• Capacity information is current.
• Price and scope align with the need.
• Risk is at an acceptable level.
• The user’s values have been preserved.
• Critical uncertainties have not been concealed.
• Valid authority exists for the next action.
• The selection can be recorded and reassessed when necessary.

A qualified selection is not merely “an option that looks good”. It is a selection ready to become behaviour.

The chapter’s conclusion

An agent should not choose you merely because you are visible. It should not choose you merely because people talk about you. Nor merely because you are the cheapest, newest, largest or most popular.

It should choose you when:

you match the user’s real purpose, you meet mandatory conditions, your identity and capability can be verified, you have current capacity, your price and scope fit, your risk is acceptable, uncertainties are not concealed, the action pathway is safe and authorised.

It should not choose you when:

you are unsuitable, there is insufficient evidence, you lack capacity, you conceal important limits, you do not fit the user’s purpose, selection results solely from visibility or manipulation.

GBO is not about making an agent like a brand. It is about enabling the agent to make the right match.

The NOMOS Suitability Contract must therefore carry two statements together: Choose me in these circumstances.

And: Do not choose me in these circumstances. The first sets out the conditions for a suitable commercial relationship. The second places a boundary against false expectations. Once correct identity, genuine capability and verified suitability are established, selection becomes possible. But selection is still not action. An agent may have chosen the right company, product or person.

Before requesting a quote, sharing data, making a payment, publishing material or initiating a contract on the basis of that selection, another question still has to be answered:

Who authorised this action?

Finding the right option does not automatically create the right to act on a human’s behalf.

Suitability tells you whom you may choose. Authority determines how far you may go.