Putting agents inside your own product

If you run a software product, your customers have started asking the same question in slightly different words: can it just do this for me? Draft the reply, reconcile the entries, chase the missing document. The request is for an agent, though nobody calls it that. They call it a feature.

Building the first version is quick, and your engineers are the right people to do it. What takes the time is everything a multi-customer product needs around the agent - and most of that has nothing to do with your product.

Your users are not your team

An internal agent has a forgiving audience. The people using it share an employer, a set of systems, and a reason to report problems politely. An embedded agent has none of that. Each of your customers is a separate organisation with its own data, its own accounts in other systems, and a reasonable expectation that none of it touches the customer next door.

That raises the bar on three things at once.

• Whose credentials. The agent has to act in your customer's accounts, not in yours - and not in a shared one.
• Whose data. What one customer's agent retrieves stays with that customer.
• Whose record. When a customer asks what the agent did in their account, the answer has to be theirs alone.

The credential arrives with the call

The pattern we lean on for embedding is the simplest one to reason about. Your backend already knows who the user is and already holds whatever grants access to their systems. So when it calls the agent, it passes that credential in with the request. The agent uses it for that run, and it is thrown away when the run ends.

There is no fallback. If the credential does not arrive, the agent does not quietly reach for a different one. The run fails, which is the correct behaviour.

In by API, out by webhook

From your product's side the integration is two pieces. You start a run through the API - from a button, a background job, or whatever event in your own system should cause it. When there is something to report, a signed webhook tells your backend, and your product decides how to show it.

Your interface stays yours. The agent has no screen of its own that your users need to learn. It is a capability behind the one they already use.

What you keep, what you hand over

The parts that are specific to your product - what the agent should do, in what words, with which of your data - stay with your engineers. That is where their time is worth the most. The parts that are the same for everyone who runs agents on behalf of other people - isolation, identity, limits, the record of what happened - are the platform's to carry.

It is the same division of labour as payments or email delivery. You could build it. The question is whether it is the thing you want to be good at.