Guide
Adding an AI agent to existing software.
This guide is for those considering adding an agent to software already in service. It covers the decisions to make before writing code, and what determines success or stagnation.
The first decision is not technical
The temptation is to open up widely: wire the agent to everything the application can do, and let users discover. That is the surest way to produce an impressive demo and an unusable product.
An application in service has rules, edge cases and inherited inconsistent states. An agent acting on it without a defined boundary will meet those cases — and its behaviour there will determine how much it is trusted.
Starting with one task lets you observe those cases on controlled ground.
Pitfalls we have hit
These come from building the BANANA-CONTENT agent, not from a literature review.
Confusing answer and effect
An agent saying it did something has proven nothing. Success must come from the application, not from the agent's account of it.
The silent half-success
In batch processing, if partial failures do not surface explicitly, the user will believe the operation completed. That is the hardest form of lost trust to regain.
Vanishing context
If conversation state lives in process memory, a restart erases a promise already made to the user. What matters must be persisted before it is announced.
The resurrecting preference
A deleted instruction can return through a summary, a cache or an index. Check the full path of forgetting, not just the delete button.
Five decisions to make
- 01
Choose the starting task
A frequent task whose result is visible in the application and verifiable. Avoid the spectacular but rare case: it teaches you nothing about real usage, and its failure will be highly visible.
- 02
Inventory what is reachable
Which data is readable programmatically? Which functions are callable? This inventory often reveals the blocker is not where you assumed: an API exists but does not cover writing, or the reverse.
- 03
Decide the autonomy level
Reading and advising, preparing a change, executing: three distinct levels. Much of the value comes from the first. Opening execution immediately adds risk without guaranteeing benefit.
- 04
Preserve the permission model
The agent must act within the signed-in user's boundary, not with a technical account that sees everything. This decision is structural: revisiting it later is expensive.
- 05
Define what you will measure
Before starting, decide what will prove it works. "Users are using it" is not enough: is the task completed, and without manual correction afterwards?
Questions to ask an integrator
How does the agent obtain its permissions?
The expected answer: from the server, based on the signed-in user's identity. If typed text or client configuration can influence that level, it is a design problem.
What happens when an action half-fails?
A serious provider has a precise answer. If it is vague, the interface will be too.
How do capabilities evolve with our product?
Look for a versioned declaration rather than direct coupling to code: otherwise every change to your application will require rework.
Let us discuss your application.
We always start by looking at what it already exposes.