How to Create an AI Agent. Account Manager

Five people work the same client. The audit agent issued recommendations in the first week, the content agent handed over a plan in the second, the reporting agent added its own conclusions at the end of the month. Each piece was good. And before the monthly call, an account manager still spends half a day reopening reports and asking around, because there is no single place that says what, out of all of it, actually got done. This article is about the mechanism that builds that place on its own — and it isn't a new role you build. It's a property you switch on for the agents you already run.

"Account manager" is a property, not a role

Every previous guide on this site built a role: a copywriter, an SEO specialist, an audit router. This one doesn't. There's a checkbox on the agent card — "Track outcome" — and any agent can have it ticked. Tick it and that agent stops being a consultant that answers and forgets: after every completed task it remembers what it recommended, comes back after a set interval, asks whether it was done, and records the answer.

The follow-up question is asked by the agent that issued the recommendations — the only one that knows what they were. What makes the whole thing an account manager rather than a reminder bot is where the answers are stored.

The key is the site URL — which is why this is an account manager

Every tracked record is filed under two things: the agent that made the recommendation, and the site address it concerned. And the history lookup takes the address as its required argument, while the agent is optional. Leave the agent out and you get everything ever recommended for that URL, by every agent with the box ticked — the audit router, the content agent, the reporting agent, first-line support, in one list with dates and statuses.

That's the difference between a task reminder and an account file. A tracker organises work by who owns the ticket. This organises it by whose site it was for — which is exactly how an agency actually thinks about clients, and exactly the view nobody has today because each discipline keeps its own trail.

How a month looks on one account

1. A specialist asks the audit router for an audit of https://example.com. It returns the report; the system stores the recommendations against that URL and schedules the follow-up question to the same specialist.
2. Two weeks later the content agent produces a publishing plan for the same site. Same thing: stored against the same URL, its own interval, its own follow-up.
3. At the end of the month the reporting agent files its conclusions — again against that URL.
4. Each follow-up arrives on its own schedule and gets one answer, in one message, from the person who asked. Qualifiers survive: "didn't get to it", "did half of it" go into the note on the record.
5. Before the client call, any agent working that account pulls the history for the URL and sees all of it at once: what three different agents recommended, what was confirmed as done, and what was never picked up.

Each record carries one of three statuses, visible in the interface and to the agents on their next request: awaiting confirmation, confirmed: done, confirmed: not done.

Who gets the question

It goes to whoever made the request, in the chat they made it from. In an agency that is your own specialist, not the client — the people in the bot's whitelist are your team, and the follow-up runs under that same team member, so its token spend lands on their account and their personal API key if they have one.

That is the difference from a reminder in a task tracker. Nobody has to open anything, no account manager has to remember to ask, and the answer is one line in a chat the specialist was already working in.

The two settings, per agent

Both live on the agent card. The checkbox sits next to "Agent is ready to work" and "Always run in background"; the interval field is directly beneath it. The interval is per agent, which is the point — the same account gets three different rhythms:

Think in weeks, not hours

The field asks for hours and defaults to 24, which is the right unit for a homework check and the wrong one for account work. Technical recommendations sit in a developer's queue; a content plan is executed across weeks; conclusions from a monthly report are meant to be answered by the next monthly report. Ask too early and you manufacture a "not done" that tells you nothing about anyone.

• 168 hours — a week. Audit recommendations that need someone else's queue.
• 336 hours — two weeks. A content or link plan, where the question is whether it started at all.
• 720 hours — a month. Report conclusions, so the answer lands just before the next report is written.

The countdown starts from the agent's answer, not from the start of a day — so the question arrives at roughly the hour of the working day when the task was originally set.

What to add to the agents' system prompts

The checkbox handles storing and asking on its own. The prompt is what makes an agent use the account file, and it's the same three lines in every agent you tick the box on:

At the start of the task, if the request contains a site address, call
get_outcome_history for that address WITHOUT specifying an agent — you
need the full history for the site, including recommendations made by
other agents.
Do not reissue a recommendation already confirmed as done, whichever
agent made it: treat it as an established fact and build on it.
If earlier recommendations are still unconfirmed, list them in one
separate block at the top: "outstanding on this account".

The middle line is where the hours are saved. Without it three agents keep recommending the same three things to the same client for a quarter, each one unaware that the work was done in week two.

Three tools every agent already has

• get_outcome_history — the recommendation history for a site, with dates and statuses. Pass a URL alone for the whole account; add an agent key to narrow it to one discipline.
• get_pending_outcomes — the open questions: what was asked and never confirmed.
• confirm_outcome — writes the answer back: done or not done, plus the responder's own wording as a note.

Nothing to wire up — they ship with the platform, the same way the memory and credential tools do.

One account, one URL — written the same way every time

The address is pulled out of the request text automatically, and it's matched exactly. Two consequences worth taping to the wall:

This belongs in the same template line as the knowledge base from the copywriter guide: "Client: X. Site: https://x.com. Knowledge base: X." Three lines that cost nothing and decide whether a quarter of history is one file or four.

What this gives the person running the agency

• Every recommendation has a status. Not a feeling about how the account is going — a record with a date, an author agent, and an answer from a named person.
• The account is visible across disciplines. One address returns SEO, content and reporting in a single list, which is the view an account manager otherwise assembles by hand before every call.
• Patterns become visible. If one category of recommendation is always "not done", that's a question about the process — capacity, hand-off, whether the item was even actionable — not about the specialist who keeps answering honestly.
• Client reports assemble from confirmed records. "Here's what was done on your site this quarter" becomes a query instead of an archaeology project across chat threads.
• Work stops being repeated. Agents that can see the account file don't re-recommend what's already implemented, and the client notices that before you tell them about it.

The mechanic isn't about SEO

It isn't tied to the audit router, or to SEO at all — it works on any agent with the box ticked. One example from practice: a tutoring agent ran a voice lesson, and at the next lesson asked the student on its own whether the homework from last time was done, and recorded the answer. Any advisory agent has the same loop — legal, financial, a business coach, a sales consultant: advice was given, and the point is that someone acts on it.

Pointed outward, the same mechanic covers the client side when the client talks to the bot directly: an automatic nudge with no account manager involved, and — when "not done" answers start stacking up on one account — the earliest churn signal you'll get, while there's still time to act on it.

What it doesn't do

• The question goes out over Telegram, to a chat the requester actually uses. No chat, no follow-up — tracking is skipped silently.
• The question is asked once. If nobody answers, the record stays at "awaiting confirmation"; there is no second reminder and no escalating nag.
• The status is binary. Partial progress lives in the note, not in a percentage, and nothing computes an implementation rate for you.
• A task with no URL in it is still tracked, but it lands outside every account file — it will only ever come back through the open-questions list.

Testing and tuning

Set the interval to one hour on two different agents, then run both against the same URL from your own account — an audit and, say, a content task. Answer the two follow-ups differently: one yes, one "started it, didn't finish." Then ask a third agent for something about that same site. The test isn't whether the questions arrive; it's whether the third agent's answer opens with what the other two already recommended. Then set the intervals to weeks.

Common mistakes

• Writing the URL a different way each time. A trailing slash, a UTM tail or a missing https:// splits one account into several, and the cross-agent history — the entire reason for doing this — quietly stops working.
• Leaving the interval at 24 hours. Account work runs in weeks. Asking about changes still sitting in a queue manufactures a "not done" that says nothing about anyone.
• Ticking the box on every agent at once. Every answer from every agent then generates its own question, and the specialist's chat fills with "so, did you do it?" Start with the agents whose output is supposed to become work.
• Ticking the box and not touching the prompts. Then the account file accumulates and nothing reads it: three agents keep issuing the same recommendations while the answers pile up beside them.
• Expecting a second reminder. The question is asked once. If your process needs persistence, that's a human's job, prompted by the open records — not something the agent does on its own.
• Using the log against people. It exists to make the next step obvious and the quarterly report true. Point it at a person instead of the process and you'll get careful answers, which is the one thing that makes the whole record worthless.

Максим Сафьянов

I build Оракул: a self-hosted AI-agent orchestrator for digital and SEO agencies — unlimited roles, your own server, source code handed over at setup.