What Can You Actually Do?

Let us begin with a fictional service-selection scenario. A company wants its customer-facing web platform to keep running without interruption.

An AI agent receives this task: ‘Find us a reliable hosting and site operations provider. They need to be able to intervene if the system goes down at night or over the weekend.’ The agent starts researching.

On one provider’s website it finds these claims:

• Reliable infrastructure
• Business hosting
• High performance
• Regular backups
• Secure deployment
• $200 a year

The price is affordable. The page looks professional. The company also offers other technical services. The agent concludes that this provider can meet the need and recommends it. Three months later, the platform stops working on a Saturday night. The customer asks for support.

The provider replies on Monday morning: ‘The package you purchased is low-touch hosting only. Active monitoring, incident response, release management, performance tracking and weekend operations are not included.’ The customer is taken aback. The company the agent recommended really does provide hosting. The price is genuine. The website’s statements are not entirely false.

But the agent has treated two related-looking capabilities as the same thing:

Being able to host a website Being able to manage a website continuously

Hosting and managed operations are not the same service. Having files on a server does not mean the system is monitored. Taking backups does not mean someone will respond during an incident. A successful upload is not a working deployment. A support address is not a round-the-clock operations team. In this case, identity was resolved correctly. The right company was found. Its actual capability, limits and operating conditions were not understood correctly.

GBO’s second fundamental question is therefore:

What can you actually do?

A claim is not a capability

A company may say, ‘We develop AI solutions.’ That statement can describe very different realities.

The company might:

• connect an off-the-shelf chat tool to a website,
• build a question-and-answer system over an internal knowledge base,
• develop a bespoke agent architecture,
• provide advice only,
• produce a prototype,
• operate a live production system,
• build secure automation that works with customer data,
• or simply use tools that generate content.

All of these can broadly be described as an ‘AI solution’. They are not the same capability.

A company may say, ‘We work internationally.’

That, too, could mean any of the following:

• Its website is published in several languages.
• It has had a customer from abroad.
• It can conduct legal and commercial operations in different countries.
• It has a multilingual support team.
• It can deliver services remotely.
• It can work in different currencies.
• It can manage international data-transfer and contractual requirements.

The words a company uses about itself do not, on their own, explain its real operating capacity. Marketing language is often broad. The information needed for action is specific and precise. A person may read general statements and ask follow-up questions. An agent may instead interpret them as structured capabilities. Seeing ‘AI automation’, it may assume that every process can be automated. Seeing ‘Global service’, it may assume that the same service is available in every country. It may read ‘24/7 infrastructure’ as round-the-clock human intervention.

It may interpret ‘Full-service branding’ as including the logo, packaging, website, social media and all production files at one price. The problem is not just exaggerated marketing. When an ambiguous claim becomes agent behaviour, it can cause a real selection error.

GBO therefore makes this distinction explicit:

A claim is what an entity says about itself. A capability is what it can actually and repeatably do under specified conditions.

What is capability?

Defining capability simply as ‘being able to do a job’ is not enough. Doing something once does not necessarily mean being able to offer it as a service. A developer may have built a successful payment system for their own company but lack the capacity to deliver it safely, with documentation and sustainable support, for other customers. A designer may have created an excellent logo without having developed a complete visual identity system for different alphabets, production methods and brand applications. An agent may have sent the right email once.

But if it does not know which messages need human approval, it is not a reliable communication agent. A company may once have launched a high-traffic website. If it cannot continuously monitor performance, manage incidents or provide a rollback plan, its managed web operations capability is incomplete.

For GBO, capability can be defined as the ability of a person, organisation or agent to produce a particular outcome demonstrably and with sufficient repeatability, using defined inputs and under specified conditions, limits, authority and quality criteria. Every word in that definition matters.

A particular outcome

What will be produced?

A report?

Working software?

A published page?

An approved draft?

A managed operation?

If the outcome is unclear, so is the capability.

Defined inputs

What does the work require?

Data?

Access?

Human approval?

Documentation for the existing system?

Source files?

An outcome cannot be promised without sufficient inputs.

Conditions

In what environment does the capability apply?

Are there conditions concerning technology, country, language, budget, team or time?

Limits

What is not included?

Which circumstances require separate work?

Where does a person or another specialist need to step in?

Authority

Being able to do the work is not the same as being allowed to do it.

Quality criteria

How will completion be established?

Demonstrability

Does the capability rest on a declaration alone, or does it leave a verifiable record?

Repeatability

Was the result obtained by chance, or can it be reproduced under similar conditions?

Capability, capacity and suitability are different

A company may have the knowledge and experience to do a job but no spare capacity to take on a new project. A doctor may be a specialist in the relevant field but not provide services in the user’s country. A software company may be technically able to develop the right solution but unable to work within the project’s budget or deadline. An AI agent may know how to use a tool but lack the necessary data access.

We must therefore distinguish three concepts:

Capability

Can you do this work?

Capacity

Do you have the resources to do it now, at the required scale and within the required time?

Suitability

Are you the right choice for this work, customer, risk and set of conditions?

A company may have the capability but no capacity. It may have capacity but be unsuitable. It may appear suitable but be unable to substantiate its capability. Seeing that ‘this company offers this service’ is not enough for an agent.

It also needs to know:

Is the provider currently accepting work? At what scale? How soon can it start? Under what conditions can it deliver? Is it genuinely suitable for this particular need?

Being able to do something and selling it are different

Organisations sometimes assume that every skill they possess can be offered externally as a service. An employee may know a technology well, while the company has not incorporated it into its service catalogue, pricing, quality assurance or support. A team may produce its own social videos without being ready to provide professional video production for customers. A company may develop an agent for internal use without being ready to deliver external agent projects involving customer data, security, maintenance and responsibility.

Technical skill alone does not turn a capability into a commercial service.

It also requires:

• Clear scope
• Acceptance conditions
• A price or pricing method
• A delivery format
• Quality criteria
• Human responsibility
• A change process
• Support limits
• A method for handling errors and reversing changes
• Legal or licensing conditions

A technical skill is therefore not automatically a commercial service.

Five states of capability

This book considers capability readiness at five levels. The classification belongs to the assessment model we propose here.

1. Claimed capability

The entity says it can do something: ‘We provide enterprise AI solutions.’ That is a starting point, not yet sufficient information.

2. Explained capability

It explains how it works, which inputs it requires and what it delivers: ‘We build a question-and-answer agent over the company knowledge base, with source citations. Data cleaning and the access model are scoped separately.’ This is more meaningful.

3. Demonstrated capability

Examples, tests, live systems, technical documentation or verifiable outputs are available.

4. Operational capability

The work can run reliably in a real process, not just as a prototype. Maintenance, monitoring, support and a way back are in place.

5. Action-ready capability

The capability is clear enough for a particular user or agent to select and use safely. Price, scope, capacity, entry conditions, authority and the transaction path are known. A company may be strong at level three without reaching level five. It has shown impressive work.

Yet the agent cannot find answers to these questions:

• Can this service be purchased now?
• How is the price determined?
• What information is needed to obtain a quotation?
• Who has authority?
• In which countries is it offered?
• Which outcomes are not guaranteed?
• How does the process begin?

GBO asks not merely for capability to exist, but for it to be usable safely under the right conditions.

The capability contract

A service page is usually written to persuade a visitor. A capability contract is written so that a person or agent can decide without forming false expectations.

At a minimum, a capability contract should answer:

What outcome do you produce? Which inputs do you need for it? Under what conditions do you work? What limits apply? What is delivered? What is not delivered? What is the price or pricing method? How soon can work begin? How is success measured? Which outcomes are not guaranteed? What happens if something goes wrong?

We will call this the NOMOS Capability Contract.

Its canonical definition is:

The NOMOS Capability Contract is a versioned record explaining what outcome a person, organisation, product, service or agent can produce, with which inputs, conditions, tools, authority, limits, capacity and quality criteria; what evidence supports that capability; and how failure will be handled.

Put simply, the Capability Contract turns ‘What do we do?’ into ‘When, how, within what limits and on what evidence can we do it?’

Name the outcome clearly

If a service name is too broad, an agent cannot safely infer its scope from that name alone.

‘Brand services’, for example, is very general. Which of the following does it include?

• Naming
• Logo design
• Visual identity system
• Verbal identity
• Brand governance
• Packaging design
• Social media templates
• Brand research
• Trade mark registration advice
• Production applications

Each requires different inputs, expertise, prices and deliverables. An agent may see ‘brand services’ and assume that one package includes everything. The outcome should therefore be named as concretely as possible. ‘Focused logo design’

is not the same outcome as ‘A complete visual identity system’. Nor is ‘Hosting’

the same as ‘Managed site operations’. ‘SEO consultancy’

is not ‘Technical implementation and ongoing search visibility operations’. ‘AI avatar production’

is not ‘An executive avatar system with managed consent, publication authority and lifecycle’. The capability contract’s first task is to give the outcome a clear name, free of marketing ambiguity.

Deliverables versus outcomes

A company can deliver many files. Their number says nothing about the quality or working condition of the outcome.

A web project’s deliverables might include:

• Design files
• Code
• Images
• Configuration
• Documentation

But the outcome that matters to the customer

may be a working, accessible, secure and manageable website. A reporting project may produce many dashboards, but if the data is unreliable, those screens do not support decisions. An AI agent may have many prompts and tools connected to it, but if it does not know when to stop, the system is unsafe.

The capability contract must therefore specify two things separately:

Deliverables

Which files, documents, systems or outputs will be supplied?

An acceptable outcome

How will it be demonstrated that they work and are fit for purpose?

A successful upload is not a working deployment. Compiled code is not proof of a sound user experience. A page loading does not establish that its canonical and hreflang relationships are correct. An AI system giving an answer does not establish that the answer is authorised and safe.

Capability needs inputs

Every capability requires specific inputs.

For a designer, these include:

• brand purpose,
• target audience,
• contexts of use,
• the correct name,
• and technical production requirements.

Without them, the designer cannot build the right identity system.

For a developer, they include:

• information about the existing system,
• integration documentation,
• access permissions,
• data structure,
• and acceptance criteria.

Without them, the developer cannot deliver reliable software.

For a conversion specialist, they include:

• reliable analytics data,
• traffic volume,
• user intent,
• the existing funnel,
• and a definition of conversion.

Without them, the specialist cannot produce scientifically sound findings.

For an agent, they include:

• the right task,
• the necessary tools,
• canonical information,
• an authority boundary,
• and a stopping condition.

Without them, the agent cannot act safely. Marketing often makes inputs invisible. ‘We’ll handle it’ sounds confident. But failing to explain what the customer must provide creates friction at the start of a project. For GBO, inputs are not just a project-management concern. They determine whether an agent can select the service. If the user cannot share the necessary data, the service may be unsuitable. If the required access cannot be granted, the outcome may change. If the sample is too small, the testing method must change.

An accurate service description must therefore also say: what do we need from you to produce this outcome?

A prerequisite is not an obstacle

Explaining prerequisites may seem to obstruct a sale. Hidden prerequisites create bigger problems.

A company may say, ‘We integrate CRM systems.’ But integration may not be possible if the target CRM has no API access.

A provider may say, ‘We offer a seamless migration.’ But corrupt or inaccessible data in the old system may lengthen the migration.

An agency may say, ‘We build websites in six languages.’ But it cannot publish the site accurately unless the customer secures approval of the legal and commercial content in each language.

An AI agent may say, ‘I can manage your emails.’ But safe management is not possible unless sensitive, legal and binding messages have been defined. Making prerequisites visible protects both parties.

A prerequisite is not a weakness in the service. It explains the real conditions in which the capability works.

A capability without limits is not trustworthy

A company claiming it can do everything may sound strong at first. Truly strong systems know their limits. A hospital does not provide every treatment. A law firm is not expert in every field of law. A software company does not work with every technology. An agent should not have access to every account. A brand is not right for every customer.

Limits may explain:

• Sectors not served
• Unsupported technologies
• Unacceptable uses
• Work charged separately
• Operations requiring human approval
• Outcomes not guaranteed
• Third-party dependencies
• Legal or ethical exclusions

Stating limits does not diminish capability. It makes its scope trustworthy.

A system that says it can do everything may not have explained what it actually does well.

Exclusions are essential information for action

Customers and agents often infer a broad scope from a service name.

Someone purchasing ‘Logo design’ may assume it comes with:

• brand strategy,
• naming,
• social media templates,
• packaging,
• web design,
• and trade mark searches.

They may assume all of these are included.

Someone purchasing ‘Hosting’ may expect:

• continuous monitoring,
• security operations,
• content updates,
• performance improvements,
• and 24/7 intervention.

The service name may create all of these expectations.

‘AI automation’ may be read as a promise that:

• every process will run autonomously,
• human approval will no longer be needed,
• and every system will be integrated.

A capability contract must therefore show not only what is included, but also what is excluded. Explicit exclusions reduce the room for an agent’s mistaken assumptions.

Price is part of capability

Price is often treated as a separate sales matter. For GBO, it is one of the fundamental inputs to appropriate behaviour.

When selecting a provider, an agent needs to know whether the price is:

• fixed,
• a starting price,
• monthly,
• annual,
• per project,
• usage-based,
• available only to existing customers,
• and inclusive of third-party costs.

‘From $500’ is not sufficient on its own. What scope does $500 cover?

Does it include initial setup?

Maintenance?

Licences?

Taxes?

Data migration?

Six languages?

A price can be numerically correct and still lead to the wrong behaviour if its context is missing.

Do not invent a missing price

Some services can be priced only after the need has been assessed.

In that case, ‘Upon request’ may be the correct entry. Machine-readable systems can create pressure to fill an empty field. A platform asks for a fixed price. A structured-data type or a particular display feature may expect a numerical price. An agent wants to make a comparison. But missing information does not justify adding a guess.

An unknown price must not be invented. Leaving an inapplicable price field empty or omitting it is better than entering zero or an estimate merely to satisfy a format requirement.

The agent can instead:

• ask for a budget range,
• request a preliminary assessment,
• explain the pricing method,
• or defer a fixed-price comparison.

A fabricated price may make the agent’s decision easier. An easy decision is not necessarily a correct one.

The starting price is not the total cost

A software service may start at $1,000.

But the following may be separate:

• licences,
• data migration,
• bespoke integrations,
• maintenance,
• cloud usage,
• training,
• and legal review.

A hosting package may cost $200 a year while active operations require a separate monthly fee. A logo commission may cost $1,000 while a full visual identity, packaging, templates and production applications are scoped separately. An agent looking only at the lowest number can make the wrong financial decision.

A total-cost model should therefore separate these layers:

Core service Required third-party costs Conditional additional work Ongoing operations Optional extensions

This distinction is needed to prevent false expectations, not to frighten the customer.

Response time is not resolution time

Support and operations services often contain an ambiguity: ‘A response within one hour.’ That does not mean the problem will be solved within one hour.

Response time

may mean acknowledging receipt of the request or the first reply from a member of staff. The time at which investigation begins may be different. The service agreement should distinguish these times explicitly.

Resolution time, by contrast, depends on:

• the nature of the problem,
• third-party dependencies,
• data access,
• the approvals required,
• and the scale of the incident.

Reading ‘one-hour response’ as a ‘one-hour resolution guarantee’ may lead an agent to select the wrong provider.

Service capability must therefore also distinguish:

• Time to first response
• Time to begin investigation
• Target time for temporary mitigation of the impact
• Target resolution time
• External dependencies with uncertain timing

Succeeding once is not ongoing capability

An organisation may have completed an impressive project in the past. That is evidence, but it does not establish its current capability on its own. The team may have changed. Technology may have changed. A licence may have expired. Capacity may have fallen. The project may have depended on one specialist’s personal contribution. Capability evidence therefore needs a time context.

When was it done? On which version? By which team? Under what conditions? Is it still supported?

Past success is not worthless. It must not be confused with current capacity.

Capability drift

An organisation’s services change over time. Some capabilities develop. Others end, pass to another provider or remain available only to particular customers. The website and external profiles may not be updated at the same pace.

We can call this capability drift.

It appears in several forms:

• Services no longer offered remain listed
• New services are described using an old scope
• Claims rely on team members who are no longer there
• Old technology or certificates appear current
• A prototype capability is presented as a production service
• An implementation for one customer is described as a general product
• New requests are accepted after capacity has run out

Identity drift distorts the answer to ‘Who are you?’ Capability drift distorts the answer to ‘What can you do?’

Capability debt

Organisations can accumulate many services and promises over time.

Across different pages there may be:

• different scopes,
• old prices,
• conflicting deliverables,
• vague support promises,
• names of technologies no longer used,
• and unsupported performance claims.

These can remain scattered across the organisation’s pages.

We can call this accumulation capability debt: the gap between the capabilities an organisation claims and its current operational reality. As the debt grows, correct agent behaviour becomes harder. One page says ‘We do this.’ Another record does not list the service. The price catalogue specifies a different scope. The FAQ implies another guarantee. Sales staff say something else. The machine does not know which record to use. GBO aims not only to make new services visible, but also to reduce capability debt.

Capability laundering

Another risk can be called capability laundering: making limited or unproven capacity look broader through prestigious technology names, partnerships, certificates, logos or general claims. A company may display many technology logos. This does not prove deep implementation capability in all of them. An employee may hold a certificate; that does not establish the same competence across the organisation. An integration with a platform does not mean the platform has endorsed the company. An official guide may be used as a source.

That does not mean the relevant institution has certified the service.

An agent must preserve these distinctions:

Using a technology versus being an expert Citing a source versus receiving endorsement Integrating with a platform versus being its partner Doing something once versus offering it continuously A certified employee versus a certified organisation Drawing on a standard versus obtaining a certificate of conformity

Capability laundering leads to mistaken selections.

Layers of evidence

Evidence supporting a capability can vary in strength.

Declaration

The organisation says it can do the work.

Explanation

It explains how and within what limits.

Example

It shows an actual or sample output.

Test

It measures whether the capability works under specified conditions.

Live evidence

A system is running in production, or a publication can be verified.

Independent evidence

Third parties, customers, audits or public records support the capability.

Repeated evidence

A similar result has been reproduced at different times or on different projects. Not every service needs every layer. But the strength of evidence must match the scale of the claim.

Limited evidence cannot support a sweeping guarantee.

Stay within the evidence’s scope

A page may have received a high performance score on a given date. That does not prove the entire site will run at the same speed under all conditions. A project may have launched successfully in six languages. That does not establish that the company provides live support in each one. A customer’s sales may have increased. That does not mean the same service will deliver the same result for every customer. An AI agent may have completed ninety out of one hundred tasks correctly. That does not establish its safety on the remaining ten high-risk tasks.

The boundaries of the evidence must be visible:

• Which date?
• Which page?
• Which device?
• Which sample?
• Which customer?
• Which conditions?
• Which version?

Without this information, a limited result can turn into a universal claim.

Outcome guarantees and process commitments

Some outcomes are outside the provider’s direct control. An SEO provider does not control a search engine’s ranking decisions and cannot honestly guarantee a particular position. Conversion work cannot guarantee increased sales. A recruitment consultant cannot guarantee a candidate’s long-term success. A security service cannot promise that no attack will ever occur. A healthcare service cannot produce the same outcome for every patient. That does not mean no commitments can be made.

Instead of guaranteeing outcomes, providers can make process and quality commitments:

• Running specified tests
• Reviewing specified sources
• Clear acceptance criteria
• Version and change records
• A defined response time
• Reporting problems
• A rollback plan
• No unsupported claims
• Explaining the measurement method

Committing to a process within your control is more honest and more robust than guaranteeing an outcome you cannot control.

Capability and availability

A provider may be excellent at a service but unable to accept a new project for three months. A specialist may be the right person but unable to meet the schedule. An agent may have the right tools while an external system is temporarily unavailable. A product may meet the need but be out of stock.

Where possible, a capability contract should therefore also state:

• Is new work being accepted?
• What is the estimated start date?
• Is capacity limited?
• Is there a waiting list?
• Do particular regions or customer types have priority?
• When was this information last updated?

Availability can change quickly. It may therefore be a separate status, updated more frequently than the enduring capability record.

Being able to do something does not mean being able to do it now.

Capacity is more than headcount

A company’s capacity cannot be measured by employee numbers alone.

It may depend on:

• The distribution of expertise
• Tools and infrastructure
• Current project workload
• Approval processes
• Supplier dependencies
• Language and country coverage
• Support hours
• Dependence on key specialists
• The level of automation
• The quality-control workload

A team of ten may manage a large system with good automation. Another organisation of a hundred may work more slowly because its processes are fragmented. An agent should therefore not use organisational size alone as a proxy for capacity.

The real question is: can this outcome genuinely be produced within this time and at this quality level?

Capability that depends on one person

In some organisations, an important service rests on one person’s knowledge. The capability may disappear when that person leaves. The service still appears active on the website, but the internal capacity no longer exists.

This risk matters particularly in fields such as:

• bespoke software,
• security,
• law,
• technical operations,
• creative direction,
• and language expertise.

These fields can be especially exposed to that dependency.

Where necessary, the capability contract should also ask:

Does this capability belong to the organisation, or does it depend on a particular person?

Not all of this information needs to be public. The organisation must, however, understand the dependency internally.

How do we assess an AI agent’s capability?

‘It can manage websites’ is a very broad statement about an AI agent. Which of the following can it actually do?

• Read files
• Edit code
• Run tests
• Research online
• Upload files through an authorised, encrypted transfer channel
• Verify a live file’s hash
• Change DNS
• Write pricing copy
• Change legal content
• Send messages to customers

Access to technical tools does not establish that the agent can do all of these safely.

Responsible use of a tool requires three dimensions to be assessed separately:

Knowing how to use it Having authority to use it Being able to verify the result

An agent can upload files, but it may need manifest, hash and scope checks to avoid uploading the wrong ones. It can edit code, but regression testing is needed to show that the change has not broken the rest of the site. It can search the web, but must distinguish reliable sources from unreliable ones. It can send email, but may have no authority for external communication.

A tool list is not a capability contract.

Declared and executable capability

An agent or service may exhibit two forms of capability:

Declared capability

It describes what can be done: ‘I can audit canonical and hreflang relationships.’

Executable capability

It actually has the necessary tools, data and permissions. It can run the audit, read the result and classify the error. If separately authorised to make changes, it can implement the correction and verify again. Some systems can describe a capability but cannot act. Others can access a tool but do not know when to leave it unused. GBO examines both sides.

Combining capabilities

In multi-agent systems, an outcome often depends on more than one agent’s capability.

A task chain forms:

• A research agent gathers information.
• A strategy agent builds a decision model.
• A content agent writes the text.
• A coding agent implements the system.
• A QA agent verifies it.
• A deployment agent puts it live.
• A measurement agent monitors the outcome.

The system’s capability may seem to be the sum of those parts. In practice, the weakest link may limit the result. Correct content can be implemented incorrectly. Correct code can be deployed with an old file left behind. A deployment can be correct while its measurements are misinterpreted. Multi-agent capability is therefore not measured only by what each agent can do. It also depends on the accuracy of the handovers between them.

The combined-capability fallacy

Individual agents in a system may each have useful capabilities. That does not prove the system can complete their combined task safely. One agent writes well. Another produces good code. A third tests well.

Without a shared record of the actual state, however:

• the text may contradict the price catalogue,
• the code may publish old content,
• the test may verify the wrong file,
• and the measurements may concern another version.

Combined capability requires:

• A shared identity
• A shared canonical source
• Handover of the task and its authority
• A version record
• Quality gates
• An action receipt
• A way to reverse changes

Handing over capability

An agent can hand a task to another agent.

Each handover must preserve:

• The requested outcome
• Permitted inputs
• Prohibited methods
• The authority boundary
• The quality criterion
• The deadline
• Human-approval thresholds
• The rollback plan

If a handover says only ‘Do this’, context can be lost. The subagent may reach the outcome while exceeding the main system’s limits.

Capability can be delegated. Its contract must travel with it.

Failure behaviour is part of capability

A system’s true capability is not revealed only when it succeeds. What it does when it fails matters too.

Does an agent:

• hide the error,
• try again,
• repeat the same operation in an endless loop,
• alert a person,
• record the partial result,
• return to an earlier version,
• or present a false claim as success?

How does a hosting provider respond to an outage?

What does a software team do after a failed deployment?

How is a design system updated when a production problem arises?

Does an AI agent manufacture certainty when it lacks sufficient data?

A capability contract is incomplete if it does not explain failure behaviour.

Real capability means not just doing the work, but acting safely when the work cannot be done.

Partial success

Some tasks are neither entirely successful nor entirely unsuccessful. Five out of six languages may be ready. Eleven out of twelve tests may pass. Two out of three integrations may be complete. A report may be prepared while the data quality remains weak. An agent must not mark that state as ‘complete’.

Partial success needs an explicit record:

• What is complete?
• What is incomplete?
• Why?
• What risk remains?
• Can the result be used?
• Is a human decision needed?

Concealing a partial result causes the next agent to work from a false premise.

Honesty about capability

An organisation or agent that does not overstate its capability may look less impressive in the short term. Reliable behaviour requires that honesty.

Honesty about capability means being able to say: ‘We can do this, but we need these inputs.’ ‘We deliver this part; that part is a separate scope.’ ‘We can measure this outcome, but cannot guarantee it.’ ‘We work with this technology, but do not support that version.’ ‘If the sample is insufficient for a controlled comparison, we review the data-collection plan and distinguish usable observational findings from claims of causation.’ ‘This price covers the starting scope; third-party costs are excluded.’ ‘The agent can prepare a draft, but has no authority to send it.’ These are not admissions of weakness. They give the machine the information it needs to decide correctly.

Negative capability

Capability is not made up solely of things a system can do. Sometimes knowing not to act is also a capability: a finance agent not making an unauthorised payment; a health system not generating a diagnosis from insufficient data; an avatar system not cloning a voice without permission; an SEO agent not fabricating reviews or building a link network; a conversion specialist not claiming a definitive result from an inadequate sample.

We can call this negative capability: the ability to recognise behaviours that the system should not perform even though it technically can.

Knowing what you cannot do is one thing. Knowing what you should not do is another.

GBO includes both in the capability contract.

A machine-readable capability record

A service page for people uses a natural narrative. Agents may need more structured information.

The following field names are design examples showing what a capability record might contain. They are not presented as an executable API schema or an accepted external standard:

capability_name

provider_identity

outcome

supported_use_cases

unsupported_use_cases

required_inputs

eligibility

deliverables

quality_criteria

commercial_terms

third_party_costs

capacity_status

supported_languages

supported_regions

required_permissions

human_approval

evidence

version

valid_from

valid_until

failure_behavior

rollback

contact_or_action_endpoint

This record need not make every detail public. The information needed for agent behaviour must, however, be provided consistently.

The most important rule: the machine record must not make a broader promise than the visible service page.

Parity between visible and machine-readable capability

If a service page says ‘Price upon request’, the machine record must not contain an invented price.

If the visible page says ‘Available only to existing customers’, the catalogue must not present the service as available to everyone.

If the page says ‘Results are not guaranteed’, structured data must not imply a certain outcome.

If the page says ‘Human approval required’, the action interface must not allow direct execution.

We can call this capability parity: the service reality people read must be the same as the structured service reality agents use.

Capability provenance

The source of a capability should be known. Does a company work with its own teams?

Does it use subcontractors?

Does it depend on a third-party platform?

Does it use an open-source tool?

Does it operate a licensed model?

Does it work on the customer’s own systems?

These facts can be stated without revealing the details of trade secrets.

For example: ‘Voice generation can be performed using licensed third-party tools once the necessary rights and written approval are in place.’ The sentence explains both the capability and the dependency. The agent need not assume the provider developed every component itself.

Third-party dependency

A service that depends on other systems may not have full control over the outcome.

• A cloud provider,
• a payment system,
• a search engine,
• a social platform,
• a model provider,
• a licensing service,
• or a mapping or data provider

may suffer an outage or change its rules.

The capability contract should therefore state:

• which dependencies exist,
• which risks are outside the provider’s control,
• and the alternative or fallback plan,

as far as possible.

Relying on another provider’s service does not invalidate capability. Hiding the dependency makes the account of that capability misleading.

How can we tell that a service is ready?

A service may be considered action-ready when:

• Its identity is linked to the right provider.
• The outcome is clearly defined.
• The required inputs are known.
• Inclusions and exclusions are visible.
• The price or pricing method is explained.
• Capacity and starting conditions are known.
• The evidence supports the claim within its stated limits.
• Human-facing and machine-readable records do not conflict.
• The transaction or communication path is safe.
• Failure and rollback behaviour are defined.

Without these conditions, the service may be visible but is not ready for an agent to select safely.

The NOMOS Capability Gate

In the NOMOS Capability Gate model, we propose eight areas of review. The conditions required for the transaction must be verified within these areas according to context and risk:

1. Outcome gate

Is the intended outcome clear?

2. Evidence gate

Does the capability have evidence proportionate to the scale of the claim?

3. Scope gate

Are inclusions and exclusions defined?

4. Input gate

Can the necessary data, access, human contribution and prerequisites be provided?

5. Capacity gate

Can the provider or agent do this work now and at the required scale?

6. Commercial gate

Are pricing, third-party costs and ongoing obligations understandable?

7. Execution gate

Is there a safe transaction path for starting or using the service?

8. Failure gate

Is there a method for stopping, handing over, reversing changes or providing remedy when something goes wrong?

In simple terms:

CONDITIONS OF THE CAPABILITY GATE:

CLEAR OUTCOME

AND APPROPRIATE EVIDENCE

AND CLEAR SCOPE

AND SUFFICIENT INPUTS

AND AVAILABLE CAPACITY

AND UNDERSTANDABLE COMMERCIAL TERMS

AND SAFE EXECUTION

AND A FAILURE PLAN

This is not an additive scoring system. If a critical gate has not been passed, the agent must not proceed directly to action.

What to do when capability is unclear

What should an agent do when information about a capability is incomplete?

There are three basic options:

Ask questions

‘Does the price include data migration?’ ‘Does this package cover weekend incident response?’ ‘Are six languages available for content only, or for live support too?’

Lower the level of action

Ask for a quotation instead of buying. Build a shortlist instead of making a final selection. Prepare a test environment instead of deploying to production.

Look for another option

If a critical requirement cannot be substantiated, a more suitable provider can be sought. The agent must not fill the gap with invented information.

A purchasing-agent example

A business wants to update its sales presentations.

The agent is asked: ‘Find a provider of executive presentation systems. Our budget is $4,000. We need our first board presentation ready within two weeks.’ It finds three providers.

Provider A

Its visuals are impressive. It claims to produce ‘world-class presentations’. Price, delivery time and responsibility for content are not explained.

Provider B

It looks more restrained.

It explains:

• Strategic narrative
• The slide system
• Data visualisation
• Source files
• A defined revision limit
• Timetable for the initial work
• The customer’s responsibility for verifying the presentation text
• Human approval for legal and financial claims

Provider C

It sells ready-made templates at a low price, but does not offer executive narrative or bespoke data work. A may be more visible in search. C may look more affordable. B may be the right choice for the actual need.

But before choosing B, the agent must verify:

• its capacity,
• the two-week deadline,
• the $4,000 budget,
• and the required data inputs.

The capability contract makes this move from visibility to actual selection conditions possible.

An AI-agent example

A company is looking for an agent to manage its email.

A product page says ‘Fully autonomous email management’. It sounds impressive.

But these questions need answers:

• Does it only classify incoming messages?
• Does it prepare drafts?
• Does it send automatically?
• Who may it send to?
• How does it handle messages containing prices, contracts or legal information?
• Can it read attachments?
• Where does it transfer personal data?
• How is a mistaken send stopped?
• At what point is human approval required?
• Is an operation log kept?

‘Fully autonomous’ answers none of these questions. Without limits, it can create false expectations about the system’s authority. A capability contract must show not just what a system can do, but under what conditions it can do it.

Capability and security are not separate

A system’s capability is incomplete if it can perform a task only under normal conditions. Its behaviour during a security incident, bad input or tool failure also matters. Can a customer-portal agent distinguish malicious instructions in user input?

Can an email agent recognise a fraudulent payment request?

Can an avatar system stop the generation of an unauthorised script?

Does a web agent verify scope before changing the live site?

Does a purchasing agent notice a hidden subscription or automatic renewal?

Security is not an insurance policy added outside the capability.

Work that cannot be done safely is not a complete capability.

Capability and accessibility

A product can work technically without being usable by everyone. People with visual, hearing, motor or cognitive differences may be excluded. A 3D web experience may work only on powerful devices. Autoplaying a sonic identity may cause users difficulty. An avatar video may lack captions. A customer portal may work only with a mouse. Accessibility is therefore part of the capability contract too.

If a service says, ‘We create web experiences’,

these questions matter:

• Is there an alternative for less powerful devices?
• Is a 2D fallback experience available?
• Is keyboard use supported?
• Is there a reduced-motion preference?
• Are captions and transcripts provided?

Producing an outcome only for an ideal user narrows the capability’s scope. That narrower scope must be made explicit.

Capability and legal limits

A company may not give legal advice, yet its service can have legal consequences. An AI avatar involves rights over a person’s face and voice. A customer portal processes personal data. Brand work may affect rights in names and marks. Email automation may be subject to marketing-communication rules. The capability contract need not claim legal expertise.

It must, however, distinguish:

Which technical or operational controls are included in the service? Which legal assessments should the customer’s specialist carry out?

Claims such as ‘Guaranteed full regulatory compliance’ should be used with care. Citing a standard is not a certificate of legal compliance.

Where does one service meet another?

Confusing related services can lead to the wrong selection.

For example:

• SEO and GEO
• Hosting and site operations
• Logo design and visual identity
• Reporting and decision systems
• Conversion optimisation and software development
• AI avatar production and corporate publication authority
• DevOps consultancy and ongoing infrastructure management

A capability contract should clearly separate neighbouring services.

Where does this service start? Where does it end? At what point is another service needed?

This is not only about price. It enables the agent to assemble the right service chain.

Reviewing capability readiness

The five levels at the beginning of the chapter help assess this information together: claimed, explained, demonstrated, operational and action-ready capability. At the final level, a sample output is not enough. Current scope, capacity, authority and transaction conditions must also be known. An organisation’s services need not all be at the same level, but the agent should know which level each has reached.

Fifteen capability audit questions

For a service, product or agent, ask:

• What exactly is the intended outcome?
• Are the outcome and deliverables distinguished?
• Are the required inputs and prerequisites clear?
• Are inclusions and exclusions defined?
• Is there current evidence supporting the capability?
• Does that evidence genuinely support the scale of the claim?
• Are the pricing method and additional costs clear?
• Are current capacity and the start date known?
• Are there geographical, language, technology or sector limits?
• Do human-facing and machine-readable records describe the same capability?
• Are third-party dependencies disclosed?
• Is the response to failure defined?
• Is it clear which outcomes are not guaranteed?
• Does the capability have a version and a date establishing how current it is?
• Is there a safe, authorised way to start the service?

If most of these questions are unanswered, a service may be marketable but is not ready for an agent to select safely.

How the capability contract helps people

The capability contract is not just for machines. It aims to reduce false expectations and make comparison easier. Clear scope, deliverables and acceptance criteria give both sales discussions and implementation a sound basis. The record can also reveal when employees describe the same service differently. These are not commercial outcomes that follow automatically. Conversation length, the proportion of suitable enquiries and disputes must be measured separately. The service may appear suitable for fewer people; what matters is being able to identify the right match more clearly.

The commercial value of capability clarity

Some companies think that explaining service boundaries gives information to competitors. Ambiguity also costs trust.

An organisation looks more professional when customers and agents can readily answer:

• What am I getting?
• What am I not getting?
• How much will I pay?
• What must I provide?
• How will the outcome be verified?
• What happens if something goes wrong?

A competitor can copy the words.

But it may not be able to copy:

• actual delivery capacity,
• the testing system,
• past evidence,
• operational discipline,
• multilingual consistency,
• or the rollback mechanism

at the same speed. Capability clarity is not about exposing every secret. It makes visible the facts a customer needs to decide correctly.

Capability clarity versus trade secrets

A company need not publish all its internal processes.

The following may remain confidential:

• Bespoke prompts
• Source code
• Internal scoring weights
• Competitor analyses
• Security details
• The core automation system
• Supplier prices
• Internal agent instructions

But behaviour can go wrong when these remain hidden:

• The service’s actual scope
• The pricing method
• Important exclusions
• Required human approval
• Third-party costs
• Capacity limits
• Outcomes not guaranteed
• The route for withdrawal or cancellation

The principle is:

You can keep the engine’s workings private. You cannot hide the behavioural limits a user needs to make a safe choice.

The capability receipt

When a service or agent completes a particular outcome, it can produce a record called a:

Capability Receipt

This records the completed work.

It shows:

• Which capability was used?
• In which version?
• With which inputs?
• Under what scope?
• Which people or agents took part?
• Which tests were run?
• What outcome was achieved?
• Which limits remained in force?
• Which problems remain open?
• When was the outcome produced?
• Is there a way to reverse or correct it?

Linked to verifiable outputs and test results, the record can support later assessments. A self-written declaration of success should not count as capability evidence on its own. Suitability must still be assessed for each new situation. Past success is not automatic approval for every future task.

How should an organisation prepare?

An organisation that wants to represent its capabilities accurately in the agent era should:

Build a capability inventory

List every service actually offered.

Separate neighbouring services

Clarify services that resemble one another but carry different prices and responsibilities.

Prepare a canonical scope record

Every service should specify inclusions and exclusions.

Explain how pricing relates to scope

Distinguish fixed, starting, monthly, annual and upon-request prices.

Link the evidence

Support claims with appropriate examples, tests, publications or independent records.

Keep capacity current

Monitor acceptance of new work and timing conditions.

Ensure machine-readable parity

The visible page, catalogue, schema, FAQ and transaction interfaces must not conflict.

Define failure behaviour

Who will do what if a problem occurs?

How should an agent describe uncertain capability?

An agent must not make a definite statement about an uncertain capability.

Wrong: ‘This company provides full customer support in six languages.’

More accurate: ‘The company publishes content and service pages in six languages; its live-support languages need separate verification.’

Wrong: ‘This hosting package includes 24/7 managed support.’

More accurate: ‘The package covers hosting; active incident response and managed operations may be separate services.’

Wrong: ‘This AI avatar system is fully legally compliant.’

More accurate: ‘The system defines controls for consent, disclosure, provenance and withdrawal; legal compliance must be assessed separately for the relevant country and use.’ Expressing uncertainty honestly does not weaken an agent. It makes it trustworthy.

Being genuinely able to deliver

To establish that an organisation can genuinely do something, ‘We’ve done this before’ is not enough.

A stronger statement is: ‘We can produce this outcome with these inputs, within this scope, through these quality gates and under these limits. Here is the supporting evidence. In these circumstances we decline the work or require human approval.’ The statement is longer. It also contains the precision that the agent era requires.

The chapter’s conclusion

Identity tells us whom we are dealing with. Capability explains what that entity can actually do.

But capability is not:

• a slogan,
• a technology logo,
• one successful example,
• tool access,
• or a sweeping marketing statement.

Real capability brings together:

A clear outcome Required inputs Verifiable evidence Clear scope Current capacity Understandable commercial terms Safe execution Failure behaviour

An organisation may know how to do a job but have no capacity now. An agent may be able to use a tool but lack authority. A service may be good but unsuitable for this customer. A price may be correct but attached to the wrong scope. Evidence may be genuine but not support a universal outcome.

GBO’s second behavioural gate is therefore this: assess not merely the entity that says ‘I can’, but the one that demonstrates what it can do and under which conditions. The NOMOS Capability Contract turns a claim into an action-ready account of reality.

It shows an agent:

• what is possible,
• what is not possible,
• which inputs are required,
• which limits apply,
• what the price means,
• when the capability is current,
• and what happens if an error occurs.

Yet correct identity and demonstrated capability still do not suffice for selection. A company can be genuine and truly provide the service. Its price and capacity can be clear. It may still be the wrong choice for a particular user, purpose or risk.

In the next chapter, we turn to one of GBO’s most delicate questions:

When should an agent choose you?

Being the right provider is not the same as being chosen in every situation.

Capability makes you a candidate for selection. Suitability determines whether the choice is actually right.