What does this solve?
Ready AI agents removes months of assembly: the cycle, interface, connectors, logs and billing are already done, all that remains is to turn on and configure the tone. The difficulty begins at the limit of applicability - some of the tasks are completely covered by the box, some are limited by the lack of access to internal systems in the third week of the pilot. The choice error goes both ways: your own assembly, where a subscription would be enough, eats up engineering months; the box where you need access to accounting and warehouse, gives a beautiful demo and zero results. Below are the criteria by which the decision is made before the pilot, and the pilot's procedure for checking the decision cheaply.
How it works
The word “ready” hides four different levels, and the cost of error at each is different.
| Level | What has already been done | What is being configured | Who repairs the failure |
|---|---|---|---|
| Agent function inside the product (help desk, CRM, mail, tables) | all | tone, knowledge base, templates | vendor |
| Scenario builder platform | cycle, interface, ready-made connectors | script, prompts, custom HTTP calls | you are within the platform boundaries |
| Open source framework | cycle, memory, tool strapping | everything in the code | you |
| Assembly based on the API model | nothing | all | you |
The backbone is the same for all: model, set of tools, instructions, memory, limiters, observability. The readiness level only determines which parts are covered and who to go to when the agent starts lying.
The choice is made based on the characteristics of the task, and not on the impression of the demonstration.
| Task attribute | Ready | Own |
|---|---|---|
| The task is typical for the industry, the vendor has it in the product description | yes | — |
| The data is already in the same product | yes | — |
| Need access to several internal systems at once | — | yes |
| One mistake costs money or a document | — | yes |
| The process changes frequently and at your initiative | — | yes |
| Data must remain within its perimeter | — | yes |
| There is no engineer who will accompany this | yes | — |
| Need call traces for incident analysis | check with vendor | yes |
An intermediate option - a hybrid: a box as a shell plus its own tools, connected via HTTP, webhook or via MCP. This is how the most common case is closed: the interface, correspondence history and distribution among operators are satisfactory, but there is not enough access to your data.
How to connect
1. Write down the task as an input, an output and a sign of success. Without this there is nothing to compare, and the pilot turns into an exchange of impressions.
2. Collect a basket of real examples. Appeals, letters, tickets for the past period - as is, with typos, incomplete questions and confusion. Fictitious examples overestimate any solution, including obviously unsuitable ones.
3. Ask three questions before the pilot. How will the agent gain access to data that is not inside the product - connector, webhook, MCP, nothing. Is it possible to download call traces, correspondence and the knowledge base? What exactly goes to the vendor’s side if the data requirements are strict.
4. Banish shadow mode. The agent responds, but the response goes to the person for verification, and not to the client. The percentage of hits on the same basket of examples is calculated.
5. Enable confirmation mode. The answer disappears after a person clicks it. A second metric appears: how many people edit the draft before sending it.
6. Measure the cost of a closed task. Subscription per seat, payment per conversation, payment for tokens - everything comes down to one figure per closed task and is compared with the employee’s time on the same task, including verification.
7. Decide and immediately write down an exit plan. What is taken away when leaving: knowledge base, prompts, conversation history, logs, routing settings. The lack of export is an independent argument against, regardless of the quality of the answers.
8. Leave a revision point. The volume has grown, the process has changed, the vendor has raised the tariff - the decision is revised according to the same criteria, and not due to inertia.
Useful scripts
- Answers to clients based on published documentation: the box in the help desk closes the task without a single line of code.
- First line in the messenger with escalation per person: a ready-made solution plus one of your own tools for checking the status of the order.
- Parsing incoming mail, folder layout and response drafts: agent inside the mail product.
- Draft texts and working with tables: an agent inside an office suite, where the data is already nearby.
- Morning summary on accounting, banking and task tracker: getting your stuff together, the box doesn’t fit here by definition.
- Operations that change money and documents: your own, with named operations, human confirmation and journal.
Limitations
Ready sees only its data. The agent inside the help desk knows the correspondence and knowledge base articles. He doesn’t know about the remainder in the warehouse and cannot find out until the connector appears - no matter how much you configure it.
Trails are often closed. Without access to which tools were called and what was returned, debugging is reduced to rewriting prompts at random and trusting the vendor's support.
Price increases with volume. The price for a place is cheap for a small team and expensive for a flow of requests. You need to calculate based on the forecasted volume of next year, and not on the current one.
Lock-in accumulates quietly. The knowledge base, scripts, history and markup are accumulated within the platform. Exports are checked before implementation, and not at the time of exit, when there is no longer any bargaining power.
Your own requires duty. Model updates, regression after each update, security, incident analysis - a constant load on the engineer, and not a one-time assembly on the weekend.
It's easy to overestimate yours on a demo. Prototype is assembled in an evening using ten examples. The distance from a prototype to a working process is measured in months and consists entirely of edge cases.
Common limitation of both paths. Neither the box nor its assembly fixes the crooked process. An agent, based on a contradictory knowledge base and undescribed rules, reproduces this inconsistency faster and to a greater extent.
How to check the result
Compare on one basket. The same examples are run through the finished product and through your prototype. Comparisons based on memory, reviews, or vendor demonstrations are not considered results.
See the share of escalations, not the share of responses. An agent who answers everything and sends half of it to a person for rework is worse than one who honestly hands over a third at once and does not create extra work.
Count edits. The amount of time a person changes a draft before submitting is a direct indicator of suitability and translates into minutes.
Check the edge, not the middle. A question outside the knowledge base, conflicting data in sources, an aggressive client, a request for a discount, an attempt to solicit internal details. This is where ready-made solutions break down, and this is usually not tested in pilots.
Measure the cost of a closed task in both options and add the engineer’s time for support to your assembly - otherwise the comparison will come out in favor of yours simply because the support has not been calculated.
Move the cart after updating the platform or model. Quiet degradation after an update is common, and it is only caught by regression on saved examples.
One line rule: ready-made is taken when the data is already inside the same product and the error is reversible; they collect theirs when the agent needs to go to several internal systems and the cost of an error is high.