In Fortune on 26 September, Microsoft VP SaaS AI agents may change how people reach software, but the proposition in this article is an argument, not a measured outcome. Bryan Goode argues that agents will not simply erase enterprise SaaS. The software remains the system of record and execution layer, while the agent does work people used to do by clicking between apps. That is a strategic argument, not a measured outcome. The useful distinction is that a CRM, analytics suite or ads platform can still matter after almost nobody opens the screen.
The question for B2B software is therefore not only “Is our UX good for people?” It is “Can a governed agent understand our capability and invoke it safely?”
What Bryan Goode argued, and what he did not prove
The case for the execution layer
Goode’s core point is that software value has never been only the user interface. It also lives in governed data, relationships, business logic and permissions. An agent that coordinates work across applications still needs those systems to store records, apply rules and perform reliable actions.
The Fortune commentary cites McKinsey figures that 62% of organisations are experimenting with AI agents and 39% report an earnings impact. It also cites Gartner’s expectation that more than 40% of agentic AI projects will be cancelled by the end of 2027. Those are cited figures inside an opinion argument, not Integrated.Social research and not proof that every SaaS company will evolve in the same way.
What it does not prove
It does not prove that people will stop using SaaS interfaces, that agents can safely run every workflow or that a platform with APIs automatically becomes agent-ready. Agent performance still depends on data quality, permissions, error handling, observability and a clear human decision path.
Separate the company, the system of record and the interface
A SaaS company can own a valuable system of record even if the human interface changes. A CRM can remain the authoritative customer record. An analytics platform can remain the measurement store. An ads platform can remain the execution environment. A new agent interface may simply coordinate requests across them.
That separation is useful because it stops a false binary. The interface can change without the company disappearing. The hard work shifts to ensuring the underlying system exposes authorised, intelligible and auditable operations.
Modi’s view
Agent discoverability is Modi Elnadi’s term for whether an enterprise agent can understand a software product’s capability and invoke it, not only whether a chatbot recommends the brand to a human.
I would separate being findable from being callable. A clear description, supported integration boundary, current documentation and a named owner can make a product more usable to an agent without pretending that the user interface or system of record disappears.
Agent discoverability is Modi Elnadi’s term for whether an enterprise agent can understand a software product’s capability and invoke it, not only whether a chatbot recommends the brand to a human.
Classic SEO asks whether people can find and evaluate a product. Agent discoverability adds questions about machine-readable capability: What jobs can the system do? What data does it need? What output does it produce? Who has permission? What state changes can occur? How are errors explained and reversed?
| Question already asked on this page | Findable, in the ordinary SEO sense | Callable, in this page’s sense |
|---|---|---|
| What jobs can the system do? | A person can read the description | A governed agent can tell what the product will and will not do |
| What data does it need? | The inputs are written down | The agent is not granted a wider set |
| What output does it produce? | The output is described | The output is something the agent can pass on without inventing a field |
| Who has permission? | The roles are named | The agent cannot widen them |
| What state changes can occur? | The side effects are listed | An unlisted write is forbidden |
| How are errors explained and reversed? | The recovery path is documented | The agent can stop and a person can undo |
| Will clear docs win the recommendation? | They help a person evaluate | They do not guarantee selection. Enterprise agents can be limited to approved suppliers |
Interface story versus execution story
This article is about the execution layer and agent discoverability. Our sibling analysis, Gemini Connected Apps and the SaaS interface [blocked], considers the interface-level shift. Both can be true: fewer clicks through software may coexist with more reliance on governed software systems.
Both can be true: fewer clicks through the software, and more reliance on the system of record. The interface half is Gemini Connected Apps [blocked]. This page owns only the execution half: can a governed agent invoke the product and reverse the action?
What a vendor should publish so a machine can call the product
[Image blocked: Authority Envelope diagram showing how agent actions are permitted, monitored, escalated to a named human or prohibited according to consequence, authority and reversibility.]
Decision diagram: use the control path as a planning aid, not as proof of a commercial outcome.
Capability and outcome boundaries
Document what the product can do, what it cannot do, prerequisites, supported objects and service limits. Avoid vague agent claims that cannot be verified.
Data and permission contracts
State what data is read or written, retention or residency constraints, required roles, approval steps and audit logs. An agent needs to know what is allowed before it asks a system to act.
Invocation and recovery paths
Expose stable integrations, error messages, idempotent actions where possible and a way to cancel or correct work. A reliable agent workflow needs a reversal path, not only a happy-path demo.
Evidence for buyer and machine evaluation
Publish accurate documentation, implementation guidance, security information, change notes and source-qualified use cases. These are useful to people and help an agent distinguish an actual product capability from marketing language.
A readiness review for the agent era
- Identify the records and decisions your platform owns.
- Map the actions an agent could request and rank their consequence.
- Publish or improve the capability, permission and error documentation for high-value workflows.
- Test one bounded agent flow with named data owners and a rollback plan.
- Measure accuracy, exception handling, customer impact and adoption before announcing transformation.
This is the same discipline needed when a merchant agent carries out ecommerce operations or a research agent works with sensitive material. Read our agentic commerce analysis [blocked] and the Authority Envelope model [blocked] for the controls behind that claim.
A decision framework: discoverability is not delegated authority
A product can be easy for an agent to identify yet unsuitable for autonomous execution. Treat those as separate commercial decisions. Discoverability answers whether an agent can correctly select and understand the service. Delegated authority answers whether that agent may cause a state change without a person intervening. Conflating the two creates a predictable failure mode: a team improves documentation, then assumes the workflow is safe to automate.
Use five tests before moving any operation beyond a human-initiated request. Materiality: what is the credible commercial, customer or operational consequence if the action is wrong? Decision ambiguity: does the action depend on judgement, incomplete context or a policy interpretation? Contract maturity: are inputs, expected outputs, exclusions and failure states defined well enough to test? Reversibility: can the original state be restored without creating conflicting records or downstream work? Accountability: is there a named owner who can approve exceptions, inspect the record and decide when the workflow must stop?
The answer need not be all or nothing. Low-consequence, repeatable retrieval or drafting may be agent-assisted with standard monitoring. A workflow that changes a customer record, publishes information or commits budget should have a stronger approval gate. High-consequence operations may remain human-initiated even where the agent prepares the context and recommended action. This is not a concession to slow adoption; it is a way of matching authority to evidence.
Vendor operating checklist
A vendor preparing for agent discoverability should be able to answer the following in operational terms, not only in sales language:
- Name the job and boundary. Define the business job, supported object, preconditions and explicit exclusions for each priority workflow.
- Publish the action contract. Describe required inputs, returned outputs, validation rules, meaningful error states and the version or release status that applies.
- Separate read, recommend and write. Make the authority level visible. An agent should not infer that the ability to retrieve data includes permission to alter it.
- Make identity inspectable. Specify how a calling agent is identified, which roles it may assume and which permissions are evaluated at execution time.
- Design for interruption. Provide an understandable way to pause, cancel, retry or hand work back to an operator; do not rely on a polished happy path.
- Protect the system of record. Define ownership where an agent coordinates several applications, including which platform is authoritative when records disagree.
- Record the decision trail. Retain enough context for an operator to establish what was requested, what was proposed, what was executed and who approved it.
- Govern change. Notify customers of material changes to capabilities, fields, permissions or behaviour that could invalidate a previously tested workflow.
Start with the small number of workflows that account for meaningful user value and operational exposure. A broad catalogue of loosely described endpoints is less useful than a narrow set of maintained contracts that can be tested under realistic permissions.
Counterarguments worth taking seriously
The execution-layer thesis is a useful planning lens, not a forecast that removes interface competition. People will still need interfaces for exploration, exception resolution, collaboration and trust-building. In many buying contexts, a clear human experience remains how a customer learns what a product does and decides whether to rely on it. Agent legibility should extend the product narrative, not replace it.
There is also a risk in making every function readily invocable. A more legible action surface can expose poorly governed permissions, fragile dependencies and unclear ownership. The appropriate control is not obscurity. It is staged exposure: begin with read-only or simulated operations, apply explicit approval thresholds to consequential writes, review exceptions, and widen scope only when the operating record supports it.
Finally, agent selection may not behave like open-web search. Enterprise agents can be configured around approved suppliers, existing contracts, internal policies and local data. Clear documentation improves the chances of correct use once a product is in scope; it does not guarantee recommendation, integration or commercial preference. Vendors should therefore continue to invest in product quality, customer success and human buyer confidence while treating agent discoverability as a discipline for reducing ambiguity at the point of execution.
For an evidence-led review of whether your website and product story are legible to answer engines, request a free AI Growth Audit and, for a focused agent-discoverability discussion, book a discovery call.
About the Author
Modi Elnadi is founder of Integrated.Social, a London AI growth consultancy. Since 2014 he has combined performance media with answer-engine optimisation and agentic lead systems for B2B and B2C brands. These pieces are his working point of view for CMOs, not a vendor press release.
