What does this solve?
The word “agent” in a conversation covers everything - from the “rewrite text” button to the system that creates tickets itself. Examples AI-agents are needed to get a working template instead of abstraction: what kind of input does the agent have, what tools does it have, what does it give at the output and where does it fall apart. Then the task is compared with the closest type, and you can immediately see what is missing - data, an API, or a gate for the writing action. The type of agent also determines the metric: support has one, and the error officer has another.
How it works
All types are assembled from the same parts, proportions change.
Trigger —what triggers: chat message, letter, webhook, schedule, queued event.
Knowledge —what the agent relies on: searchable knowledge base, database schema, documentation, correspondence history, rule book. Ninety percent of the agent's quality is determined by this layer, not by the choice of model.
Tools —what it can call: search, read request to the database, HTTP to an external system, sending a message, creating a task. Writers are separated from readers.
Cycle —how many steps are allowed, when to stop, what to do if the tool fails.
Output —response, draft, entry in the system, report.
Gate —where the person stands: before sending, before recording, only on exceptions.
Metrica —which shows that the agent is working: the share of closed ones without a person, the share of corrected answers, time to reaction.
| Type | Login | Key tool | Output | Where it breaks |
|---|---|---|---|---|
| Support | customer message | knowledge base search | response or escalation | gap in the knowledge base |
| Analyst | question in Russian | read request to the database | number and explanation | incorrect interpretation of fields |
| Error duty officer | event stream | error tracker, problem book | grouped ticket | noise from repeats |
| Documents | invoice or act file | field extraction, reconciliation | draft entry | non-standard form |
| Research | query topic | search and reading sources | summary with links | source undated |
| Content | brief and data | template, publication | draft material | fictional facts |
| Orchestrator | challenging task | calling other agents | collected result | error accumulation |
First line support agent
Login - message in chat or letter. Tools: search through articles and past conversations, read a client card, create a task. Gives a response or transmission to the operator with the context already collected. It breaks down on something that is not in the knowledge base: without priming real documents, the agent answers plausibly and incorrectly, and this is worse than silence. The metric is the share of dialogues that were closed without an operator, and the share of responses that were later corrected by the operator.
Analyst agent above the database
Login is a question in ordinary language. Tools: schema description, semantic layer with metric definitions, query validator, execution of a read-only query with a mandatory limit. Gives the number, the request that received it, and a clause about the period. It breaks down on definitions: “active client” is calculated differently in different tables, and the agent will take the field that is closer in name. It is treated with a written canon of metrics, which the agent must go to before making a calculation. The metric is the proportion of responses that matched the manual check.
Error duty officer
Input - stream of events from the bug tracking system or logs. Tools: reading events, grouping by fingerprint, searching for similar past tickets, creating a task. Submits one ticket per problem class with examples and frequency instead of a stream of identical notifications. It breaks down due to noise: without a frequency threshold and without splicing repetitions, it starts dozens of takes. The metric is the number of opened tickets to the number of real problems and the time from the first event to the ticket.
Agent for incoming documents
Input - file or letter with attachment. Tools: extracting fields, searching for a counterparty in the directory, reconciling the amount with the order, creating a draft document. Gives a completed draft and a list of discrepancies. It breaks on non-standard forms and on scans of poor quality, so a field of confidence and a rule are required: a discrepancy in the amount is always a person. The metric is the proportion of documents that went through without editing and the number of discrepancies caught before posting.
Research agent
Entrance - topic or question. Tools: search, page reading, saving excerpts with source addresses. Gives a summary where each fact is provided with a link. It breaks down on outdated materials and on undated sources: without a freshness filter, the summary mixes up last year’s and today’s. A separate danger is instructions inside the pages being read, so such an agent should not have writing instruments. The metric is the percentage of statements that have a working link.
Content and mailing agent
Input - brief, data, template. Tools: access to invoices from internal systems, templates, publication queue. Gives away the draft. It breaks down on facts: any numbers are taken from the data, and not from the model’s head, otherwise plausible fabrications appear in the text. Publication is always through a person. The metric is the percentage of drafts that were left without rewriting.
Orchestrator agent
Input is a task that cannot be solved with one tool. Mechanics: splits the goal into subtasks, launches subagents, collects the result. It breaks down due to the accumulation of errors - the incorrect intermediate result moves on and looks convincing. It rests on two things: each subagent returns a verifiable artifact, and there is a ceiling on the depth of nesting. The metric is the percentage of tasks where the result coincided with manual assembly.
How to connect
- Select the type from the table that is closest to your task, and rewrite four lines to suit you: input, instruments, output, gate.
- Collect twenty real entries over the past week. Not invented ones - exactly those that came.
- Go through these twenty cases by hand and write down exactly where the person went to get the answer. This list turns into a list of tools.
- Check source completeness: if half of the records in the field on which the agent relies have data, the agent will not help until the data is cleared.
- Build a reading version of the agent and run the same twenty cases. Compare with manual responses.
- Add writing instruments one at a time, each with confirmation. Cancel confirmation only after a week without edits.
Useful scripts
- Receiver of applications from advertisement sites: collects correspondence, pulls out dates and subject of the request, creates a draft order.
- Deadline guard: monitors requests that go unanswered longer than normal and reminds the person in charge via chat.
- Translator of request into task: collects reproduction, environment and expected behavior from the client’s complaint.
- Statement reconciliator: matches receipts with issued invoices and shows only what is not reconciled.
- Onboarding questionnaire: guides a new client through a setup checklist and fills out a card along the way.
- Night summary: in the morning prepares a short text on yesterday's indicators, indicating what exactly has changed.
Limitations
The broader the formulation of the problem, the worse the result. The “everything” agent loses to three narrow agents with clear boundaries, because for a narrow task it is possible to write a readiness criterion.
Types do not transfer well between entire companies. The anatomy is the same, but the definitions differ: what is considered a request, when the client is active, what document is the main one. You have to write these definitions yourself.
The agent does not replace a missing system. If tasks are not managed anywhere, and the data lives in correspondence, there is nothing to automate - first there is a place where to write.
The cost is made up of steps. A research agent who reads twenty pages for each question costs significantly more than a support agent who answers by index.
Reading agents are almost safe, writing agents require discipline: a white list of operations, limits, a log, confirmation of everything that goes outside.
Rule: the type of agent is chosen based on where the standard answer comes from; If there is no source of standard, there is no agent.
How to check the result
Take the same twenty inputs at which the agent was going, and add ten new ones that he did not see. The difference in quality between the two sets shows how well the agent fits the examples.
For each answer, check traceability: from which document or database line the fact was taken. An answer without a source is considered unreliable, even if it is correct.
View escalations. Their complete absence is a bad sign: it means the agent responds where there is not enough data.
For the agent above the database, check three responses using a manual request. The discrepancy almost always points to the definition of the metric, not the model.
For writing agents, open the magazine for the week and check ten actions for a back link to the source and for the absence of duplicates.
Repeat the test after changing the model: the same thirty inputs, the same criteria, comparison with the previous run.