We have accepted far too little from our integrations
I keep having conversations with enterprise leaders who want to do something fairly reasonable with AI, only to discover that their systems supposedly cannot support it. Their employees can perform the action in the application, but the API doesn’t expose it, the connector doesn’t include it or the MCP server only offers a few basic operations.
They are then told they need developers to build something custom. Sometimes they are told they need to replace the system. In the meantime, their team keeps doing the same manual work.
What frustrates me is how normal this has become. Businesses pay for software with extensive functionality, then pay for integration platforms, then hire more people because the two together still don’t let them do what they need.
This is particularly obvious in heavily customized ERPs and older operational systems. The standard connector might handle a customer record or an invoice, but the process the business actually relies on includes custom fields, specific amendments, and exceptions that sit outside it. Having a connector for the base product does not mean those operations are available.
The consequences reach well beyond IT. A customer waits for an account correction, an order stays blocked, or a billing problem goes unresolved because someone has to work through the missing steps. The integration exists, but the business still cannot complete the job without a person moving it along.
Agents need more of the product than the connector exposes
A connector gives another system a set of actions it can call. Those actions depend on the interfaces available and what someone has implemented against them. They might cover the published API, additional endpoints, or custom operations, but they are not automatically a complete map of the product.
That was a workable starting point when you were building a specific automation. You knew the process, worked out the steps, and built the connections needed to run it.
Now we want people across the organization to be continuously finding better ways to operate. An operations leader should be able to look at a painful customer process and ask whether the whole thing could run differently, including work that crosses several systems and departments. They should not need to know the connector catalog before they can have that conversation.
Consider an insurer handling a policy amendment. The request might arrive in a modern customer-service platform, while the policy sits in an older administration system. Completing it could also require a billing adjustment and new documents for the customer.
An agent that can retrieve the policy and summarize the request has only done part of the work. If it cannot perform the amendment, the insurer still needs someone to log in and finish it. Multiply that across the different processes the business wants to change and it becomes clear why better models alone are not enough.
We should be making the software’s capabilities available to agents, rather than asking the business to redesign its ambitions around whatever the connector happens to support.
The published API is not everything the application can do
The important thing to understand is that an application’s public API is a developer offering. It is not necessarily a complete description of the software.
When an employee uses a web application, the screens often call services that are not included in the public API documentation. Those services already perform the operations the business needs. Discovering how they work can make capabilities available that a standard connector misses.
This is the part people often haven’t considered. An action being absent from the published API does not mean the software has no way to perform it programmatically.
You need to understand the inputs, the relationships between records, and the rules the application applies. You also need to test the action and verify that it produces the intended result. That is real implementation work, but increasingly it is work agents can do.
Adding MCP does not remove the need for that depth. An MCP server can expose a useful workflow or a limited collection of actions. If the operation you need has not been made available, a standard way of calling the tools does not solve the missing capability. This is part of why I have pushed back on MCP as the default answer for enterprise AI.
Nor should we respond by giving a model thousands of tool definitions every time someone asks a question. The platform needs a deep understanding of what is available and should provide the relevant actions for the task. Discovering an operation and giving an agent permission to use it are separate decisions.
An older system does not automatically need replacing
The same expectation should extend to mainframes, terminal applications, and systems built around COBOL. These are often where important business processes live, and excluding them leaves a substantial part of the enterprise out of the transformation.
An older system may be doing its job perfectly well. The problem is that the business struggles to connect its capabilities to everything happening around it.
There are established ways to make existing mainframe operations available without rewriting the underlying application. IBM’s z/OS Connect, for example, exposes existing CICS, IMS, and other z/OS resources through APIs, including integration with programs using COBOL. IBM’s documentation
So the question is how to discover and use the required business operations, and how much effort that takes. Retrieving data from the database is not enough if the workflow needs to perform a transaction through the application’s existing rules.
Different systems require different access methods. But “it’s old” or “the connector doesn’t support that” should not automatically send the business into a replacement program.
You can have good reasons to retire a system. You should also be able to improve how the business operates while that system is still there.
Making integrations easier to build is only part of the opportunity
Low-code platforms made integration development more accessible. Their newer AI tools go further, generating workflows and connector code from natural-language requests. That is meaningful progress, and some vendors now offer agents that plan, build, and troubleshoot solutions. One current example
However, the customer’s remaining workload matters much more than whether the interface is drag-and-drop or a chat window.
Someone may still have to identify the right operation, explain the data, and specify what should happen when the standard path fails. If a required capability is undocumented, someone has to discover it. When the application changes, someone has to work out what broke.
A platform can generate a lot of code and still leave the enterprise responsible for most of that work.
I think the industry is moving toward a very different expectation: the platform should understand the applications, develop the implementation, and maintain it. The people using it should be contributing their business judgment, rather than becoming experts in how to connect the software.
That is what we are building with Monarch.
Discover the applications, then build against what they can do
Monarch starts with access to the applications, using an account with the permissions the enterprise chooses. Our agents explore how the software works and build a Product Graph, which maps the operations and relationships they discover and verify.
That gives agents something concrete to build workflows against, including capabilities beyond the published API. The graph is scoped to what the connected account can access and what discovery has established.
Documentation and existing process knowledge help check that understanding, but they do not have to be the starting specification. If a required action is missing, discovery can run again. A person can also demonstrate an operation so it can be captured and tested.
The business owner can start with the systems involved and the outcome they want. They work with us on the business rules and exceptions, without having to write a connector or manually assemble the implementation. This follows the same principle behind discovering an enterprise ontology from the systems themselves: use the software to establish what is possible, then bring people into the decisions about how to use it.
Once a workflow is understood and tested, known steps can run as deterministic code. Agents write that code, so the customer does not need to, and the model does not have to work out the same sequence again on every run. Inference remains where the task needs judgment or interpretation.
The graph also gives us a way to handle application changes. Monarch detects changes to mapped operations, repairs affected paths, and tests the result. Workflows that use the repaired operation can then reuse that correction, with human review where required.
This matters because an integration that works on the day of the demo is not enough. The enterprise needs it to keep working without continually sending people back to rebuild it.
Put the human in the lead
The business owner’s job should be to decide what outcome matters, set the limits, and assess whether the workflow is delivering.
For example, they might want routine account changes completed without their team touching them, with unusual cases brought to someone who can make the right decision. They should be able to inspect the work, change its authority, and stop it when necessary.
That is what I mean by human in the lead.
Human review still matters, but it should serve a specific purpose. If employees spend their days approving routine steps or finishing the actions the agent cannot perform, we have given them another operational queue rather than a bigger opportunity.
I want those people focused on the customer problems we are not solving today. That requires giving them tools that can actually carry out the work, and changing their responsibilities as that becomes possible.
Keeping someone accountable also means giving them the authority and support to do the job. Their name appearing in an audit log is not enough.
Start with the work your current integrations cannot finish
I think the model of continually asking enterprises to build and maintain their own connections will become increasingly hard to justify. The work still needs to happen, but agents should take on far more of it.
That does not mean ripping out every integration that already works. It means applying a much higher standard to the next platform you buy and the next project you approve.
Look for an important process that is currently constrained by an awkward system, a missing action, or a maintenance-heavy custom integration. Give it a business owner and a measurable customer or operational outcome, then test it within a controlled scope.
Make the vendor demonstrate the part that is difficult:
- Can it perform the required action, including your custom process?
- How does it discover a capability that is missing from the published API?
- What do your employees or developers still have to build?
- How does it verify the result and recover when something goes wrong?
- Who does the repair work when the application changes?
That is a much better test than watching a familiar CRM action run successfully.
Your organization has already invested in software with substantial capabilities. Before accepting another long project or another team doing manual work, find out whether agents can make more of those capabilities usable.
The limits of your connector should not become the limits of your business.
Frequently asked questions
Does an API connector expose everything an application can do?
No. Its coverage depends on the available interfaces and the operations implemented in the connector. Custom processes and actions available inside the application may require additional discovery and implementation.
Can agents use older systems without replacing them?
Yes, where suitable access routes exist. The important test is whether the agent can complete the required business operation through the application’s rules, rather than merely retrieve its data.
Does agentic integration remove human oversight?
No. It changes the work people need to do. Agents can take on discovery and implementation while people remain responsible for business objectives, permissions, and decisions that require their judgment.