Can an AI agent work with software that has no API?
Usually, yes. If a system has an API, sends webhooks, exports files, accepts email, or has a web page a person can use, an agent can work with it through a connector built for that system. The connector is ordinary code with a narrow job, and the agent calls it as a tool.
Ways in, from most to least reliable
Most business systems offer at least one of these. We pick the most reliable one available for each system:
| Way in | When it fits | Trade-off |
|---|---|---|
| API | The system publishes one, even if no AI product supports it. | Most reliable. Needs keys and respects rate limits. |
| Webhooks | The system can notify another system when something happens. | Lets the agent react right away instead of checking on a schedule. |
| File export and import | CSV, Excel, or PDF reports on a schedule. | Reliable but not instant. Good for daily jobs. |
| The system sends or accepts structured email. | Works with older systems. Parsing needs tests. | |
| Web page | A person logs in and clicks through forms. | Works when nothing else does. Breaks when the page layout changes, so it needs monitoring. |
Keeping the agent inside its limits
An agent with access to your systems needs clear limits. Each connector does one narrow job, such as "look up a policy" or "create a draft invoice", and does not expose the whole system. Each tool has its own budget for how often it can run on a task.
Tools that read data can run freely. Tools that write data, send messages, or move money can be set to wait for a person's approval. In our own products, the agent proposes the action, a person approves it, and the approved action then runs exactly as it was shown, with no model involved in that final step. Sub-agents get read-only access.
Keeping passwords and keys out of the agent
Connecting an agent to your systems means handling credentials. We keep API keys and passwords outside the environment where the agent runs. The agent calls a tool, and the tool adds the credential on the way out, so a prompt injection or a bug in the agent cannot reveal a key it never had.
Incoming events get the same care. Every webhook we accept is checked for a valid signature before any agent sees it, and repeated or looping events are filtered. In our own operations, 35 webhook routes from seven sources, including GitLab, Linear, Sentry, PagerDuty, and Gmail, feed our agents, and each request is checked for a signature. One service we rely on offers no way to sign its requests, so we wrote a signing scheme for it.
What we have built
Our own products connect to Todoist, Notion, Google Calendar, Telegram, WhatsApp, and Discord, and our agents work through custom MCP servers that hold shared state. We have also built a tool-calling layer that lets one agent investigate cost changes across dozens of billing and usage data sources on AWS, Google Cloud, and Azure.
For a client, the audit lists each system a job touches and the best way into each one. If a system offers no way in, the plan says so.
Getting this set up
If you want this set up for an agent you already run or one you plan to build, start with the one-week audit. It ends with a ranked plan and something working by Friday, and larger builds are quoted in writing after it.
Questions
Can AI automate a desktop or legacy system with no API?
Often, through its file exports, email, a database it writes to, or a web interface if it has one. The audit checks what each system offers and tells you which route is reliable enough for daily use.
Is it safe to give an AI agent access to our business systems?
It can be, with narrow tools, per-tool limits, credentials kept out of the agent, and approval required before any write, send, or payment. Every action is recorded in a trace.
What is an MCP server?
Model Context Protocol (MCP) is an open standard for exposing tools and data to AI agents. An MCP server wraps a system, such as a CRM or database, so any compatible agent can use it through the same interface.