Book a time
An Agent Tool Integration Engineer connects AI agents to outside systems through tightly scoped interfaces. The systems might be a SaaS product, an internal service or a database. The job is to make sure the agent can act only where it is permitted, and fails safely when something goes wrong.
Agents are changing this role because they now help build the work as well as use it. They can read API documentation, draft a connector and suggest tests in minutes. That makes the first version cheap. It makes the judgement about what the agent should be allowed to do more important, not less.
This piece covers what agents already handle in this work, what still needs a person, and what that means for your next hire.
What agents already do
We have no specific reporting to cite here, so this section describes general working practice rather than named products or figures.
Coding assistants can turn an API specification into a first-draft adapter. They write the request and response handling, map fields, and produce boilerplate for pagination, retries and rate-limit back-off. They can draft a tool schema from an existing endpoint and write documentation for it.
They also help with testing. An agent can generate a first set of contract tests from a schema, produce sample payloads, including malformed ones, and summarise a batch of failed tool calls from logs. Reading traces to group errors by type is slow for a person and quick for a model.
Routine maintenance is moving the same way. When a vendor changes a field name, an agent can spot the drift and propose the patch.
Where agents help and a person decides
Much of the work is shared. The agent drafts, and the engineer judges.
- Tool schemas. An agent can propose names, parameters and descriptions. A person has to check how a model actually behaves with them, then narrow parameters, replace free text with enums and rewrite error messages so the model can act on them.
- Test suites. Generated tests cover the obvious cases. A person adds the cases that matter: an expired token, a partial write, a response that arrives twice, a record the user should not see.
- Trace review. An agent can cluster failures. The engineer decides whether a failure is a bad schema, a bad permission or a model being led astray, and what to change.
- Protocol work. Drafting an MCP server is increasingly quick. Deciding what it exposes, and to whom, is not.
A connector that works in the demo has proved nothing. A connector that fails safely has.
What still needs a person
The core of the job is deciding what an agent may and may not do. That is a question about risk, and a model drafting its own boundaries is not a safe answer.
Permission design. Someone has to choose scopes, decide between per-user and service credentials, separate read from write, and set approval steps for risky actions. Convenience pulls towards broad admin keys. A person has to resist that and own the consequences.
Threat thinking. Tool output is untrusted. A web page or a document can contain instructions aimed at the agent. Defences include permission boundaries, egress limits, confirmation for sensitive actions and good logging. Wording in a prompt is not a defence on its own. Anticipating how someone will try to talk an agent into an unauthorised action takes an adversarial mindset that has to be taught and tested by people.
Containing failure. External systems misbehave. They time out, return odd shapes, change without notice or half-complete a write. Deciding on fallbacks, what to retry, what to stop and what to tell the user is design judgement tied to your customers and your reputation.
Building a pattern others can follow. The aim is that other engineers can add connectors in a repeatable way. That takes taste, documentation and some persuasion inside a team.
What this means for who you hire
The first draft of an adapter is no longer the scarce skill. Someone who only writes glue code against well-documented APIs is losing value, because an agent does that part quickly.
The profile gaining value is the integrations engineer with security instincts. They know auth and OAuth in detail, they think in threat cases, and they test the unhappy path first. Agent experience helps, but it is thin in the market because protocol work around agents is new.
Be careful about over-indexing on agent buzzwords. Most candidates are strong in one of three areas: API integration, security or agent work. Few have all three. A sound integrations engineer with security instincts, who is willing to learn agent behaviour, is usually the better bet than someone fluent in the vocabulary and light on production scars.
In the first months, a strong hire should ship a small set of reliable adapters for the systems customers ask about most. Each should have a documented schema, least-privilege access and tests covering contract and security cases. Tool errors should become visible and traceable.
How to spot a strong candidate
Ask them to walk through an integration they built end to end. Listen for auth, scopes, schema design and what happened when the external system misbehaved. Strong people describe threat cases and tests without being asked. Be wary of anyone who talks only about happy paths or demos.
“Tell me about an integration you built with a third-party API. What went wrong in production, and what did you change?” A good answer names a real failure, such as rate limits, schema drift or partial writes, and the fix and test added afterwards. Worry if they describe only the build, or blame the vendor without changing their own design.
“An agent reads a web page that contains instructions telling it to send customer data elsewhere. How do you defend against that?” A good answer treats tool output as untrusted and covers permission boundaries, egress limits, confirmation for sensitive actions and logging. Worry about anyone who relies on prompt wording alone.
Where to find them
The title varies between companies, so searching by title misses people. Related titles include MCP Integration Engineer, Connector Engineer, Agent Integrations Engineer and Tool and Integration Engineer.
- Integrations and platform engineers at SaaS vendors. Connectors, OAuth and webhooks are daily work for them.
- Workflow automation engineers and systems integration specialists. They are used to brittle external systems.
- API security and developer tooling teams. These people bring the threat mindset.
- AI platform companies and agent start-ups. They employ the closest matches.
- Open-source contributors to protocol servers and connectors, whose public work you can read.
Our own analysis, drawn from the role profile in our job families library and recent public reporting on how agents are used in this work. Titles and practice vary by company.