The short answer. In many mid-market software products, an AI agent can access the data through the API but still cannot use the product safely. Many software products were built on the assumption that a person sits in front of the screen. The code behind the screen enforces the business rules, the login identifies the person, and the audit log records the name of a user. When a customer’s AI agent uses the product through the API instead, each of those assumptions can fail.
So opening a product to agents is often a modernization project. The API has to apply the same rules as the screen and accept narrow access that a customer can revoke. It also has to handle retries and loops safely, and record whether a person or an agent made each change.
Five questions, set out below, test whether each important workflow is ready for a customer’s agent.
Research Grounding
Bain, May 20, 2026. Bain advises software vendors to expose your software’s capabilities in machine-readable, well-documented, and composable forms. It recommends separating the user interface from the logic and adding agent-specific, role-based access control; rate limits; and auditing. Bain also names the alternative: agents will resort to scraping your web pages and automating clicks.
Gartner, September 23, 2026. Gartner predicts that by 2028, ungoverned AI agent abuse will drive 25% of enterprise breaches. Gartner says this will require zero-trust governance and agent-specific kill switches.
Gartner, September 15, 2026. Gartner predicts that by 2030, 80% of organizations with public-facing AI will have experienced a cost exhaustion attack. It recommends treating AI token costs as a cybersecurity indicator.
These sources do not show that customer agents will replace the screen next year. Bain’s May 7 research sizes the US agentic opportunity for software vendors at $100 billion and says vendors capture about $4 billion to $6 billion of it today. Adoption is early.
Security, cost and control problems arrive before agent adoption becomes common. The enterprises in Gartner’s breach prediction are the customers of a portfolio company. Their security teams will ask vendors how an agent’s access is scoped, stopped and recorded, and many mid-market products cannot answer yet.
The PE Translation
A portfolio company can look ready for agents in a management presentation. It has a public API, an AI roadmap, and a few integrations with well-known platforms. A board then funds agent access as an integration sprint.
That budget usually covers new endpoints and documentation. It rarely covers the work underneath. In many mid-market products, the rules that keep data correct live in the screen. They sit in front-end code, in the controllers behind each page, or in database procedures that only the screen calls. The API was often added later for a specific integration, and it may write to the same tables without passing through those rules.
A person using the screen cannot break a rule the screen enforces. An agent that calls the API directly can break that rule, and it can do so across many records in a few seconds.
Some agents now operate the screen itself, clicking through pages the way a person does. Those agents do pass through the screen’s rules. They are slow, they fail when the screen changes, and the product usually records their actions under the login of the person who set them up. The questions about access and audit therefore apply to them as well.
Opening a product to customers' agents is often a modernization project, even when the budget request describes it as an API project.
The work that makes it safe is the same work a modernization plan would include anyway. Business rules move into services that both the screen and the API call. Identity changes so a customer can give an agent limited access without sharing a person’s login. Write operations accept a key that prevents duplicates when a request is retried. Logs record the agent as well as the person who authorized it.
None of this requires a rewrite. It can be done one workflow at a time, starting with the workflows customers are most likely to automate. That lets management sequence and fund agent readiness during the hold.
Workflows are rarely independent. Two workflows often share tables, database procedures and triggers. Fixing the rules for one workflow usually touches the others, so the first workflows take longer than the later ones. Issue 14 explained why modernization estimates come in too low, and this work needs the same line-by-line estimate.
The work affects the business in three ways.
Retention. A product that agents can use safely can stay inside the customer’s automated workflows. A product that agents can only scrape is fragile. Competitors that offer cleaner machine interfaces can use that weakness when they sell against it.
Margin. Agent traffic without per-customer limits can raise infrastructure and model cost for one account without any change in what the account pays.
Risk. An agent that changes records incorrectly through the product creates an incident at the customer, and that incident can become part of the renewal conversation.
Issue 8 asked whether a company can change what it charges when agents do the work. This issue asks what engineering has to change before agents can do the work safely.
A buyer’s technical team can compare the AI story in the management presentation with what the API can actually support. If the API bypasses the rules or cannot tell a person from an agent, the buyer will treat the remaining work as a cost it has to fund after closing. That cost appears in the plan the buyer underwrites, next to EBITDA and retention, rather than as a separate discount for agent readiness.
Operator Experience
An integration layer relies on the API it calls to enforce the business rules.
Earlier in my career, I built an enterprise service bus for PLM software. The end systems supplied their own APIs, and my team built the integrations on top of them. We added a few checks, but we relied on each system’s API to enforce its business rules.
In PLM, the most important rules are lifecycle rules. You can't edit a released revision of a part in place. A change has to go through a controlled process that creates a new revision. An API that allowed a direct edit would let every integration corrupt the history of what was built.
A customer’s AI agent is in the same position as that integration layer. It relies on the product’s API to enforce the rules. If the API does not enforce them, nothing between the agent and the data will.
Most business software has rules of the same kind, even when nobody calls them lifecycle rules. An invoice that has been sent cannot be edited. A discount above a limit needs approval. A closed order cannot receive new lines. The question is where each rule is enforced.
An engineer can answer most of this by showing the code. Pick one rule that matters, such as the discount limit, and ask an engineer to show where the screen enforces it and where the API enforces it. Ask whether the endpoint that creates an invoice accepts a key that stops a retried request from creating a second invoice. Ask how a customer gives an agent access today, and what the audit log records when that agent changes a record. Those four answers usually show how much modernization work sits between the current API and safe agent access.
Board Question
If one of our largest customers wanted its AI agent to use our product tomorrow, what could that agent safely do without a person touching the screen?
Five Questions to Ask Before Opening the Product to Customers' Agents
The five questions form a sequence. A workflow is ready for agents only when it passes all five.
CHECK | WHAT IT TESTS |
|---|---|
1. Reachable | The API can perform the workflow the customer wants to automate |
2. Same rules | The API applies the same business rules as the screen |
3. Delegated access | A customer can give an agent narrow, expiring access and revoke it |
4. Bounded | Retries, loops and heavy traffic cannot create duplicate records or unlimited cost |
5. Traceable | The company can show whether a person or an agent made each change |
1. Which of our important workflows can an agent complete through the API today?
The head of product and the CTO answer this together. A weak answer is the API covers the core objects. A customer automates a workflow, and a workflow usually spans several objects.
2. Does every API write go through the same validation and business rules as the screen?
The CTO or the lead architect answers this. A weak answer is the screen does the checks and the API writes to the tables.
3. Can a customer give an agent limited, expiring access and revoke it without disabling a person’s account?
The security lead answers this. A weak answer is they can create an API key for a service user.Issue 4’s Revocation Test applies here to credentials that customers create.
4. What stops one customer’s agent from creating duplicates or running up unlimited load and cost?
The platform lead answers this. A weak answer is we would see it on the monthly cloud bill.
5. Can we show, record by record, whether a person or an agent made a change?
The security lead answers this. A weak answer is everything is logged under the user who owns the key.
Three Decisions
1. Run the five checks on the ten workflows customers are most likely to automate
Choose the workflows with the head of product and the customer success lead. Record which checks each workflow passes, what fails, and who owns the fix.
2. Fund rule consolidation before funding new agent interfaces
Where the rules live in the screen, move them into services that the screen and the API both call, one workflow at a time. Estimate this work line by line, as Issue 14 described. Do not approve a new agent connector on a workflow that fails the second check.
3. Build delegated access, limits and agent-aware logging once, as shared platform capabilities
These three capabilities should not be rebuilt for each AI feature. The platform should provide each mechanism once. Each workflow should then set its own limits on top of it, because a sensible limit on invoices differs from a sensible limit on reports. Give the shared capabilities one owner, one budget and a completion date inside the hold.
One Number for the Next Operating Review
Agent-ready workflow coverage: the percentage of priority customer workflows that pass all five checks end to end.
The number shows how much of the product a customer’s agent can use safely today. Report it at each operating review, because the trend shows whether the modernization work covers the workflows that matter.
Board Takeaway
Having an API does not make a product ready for customers' agents. If the product’s rules live in the screen and its identity model assumes a person, safe agent access requires modernization work.
Before funding another agent integration, find out which important workflows already apply the same rules, access controls, limits and audit records as the screen.
Portco Brief is a weekly briefing for PE operating partners and portfolio company executives focused on technology, AI, and value creation. If this was forwarded to you, subscribe at portcobrief.com.
Sources
Bain & Company, Agentic AI and the New Complexity Trap in Enterprise Software, May 20, 2026.
Bain & Company, SaaS' next $100 billion opportunity could come from agentic AI, May 7, 2026.
Gartner, Gartner Security & Risk Management Summit EMEA 2026: Day 2 Highlights, September 23, 2026.
Gartner, Gartner Unveils Top Strategic Predictions for 2027 and Beyond, September 15, 2026.