The agent as a brain

The end-to-end use case the MCP server was built for — an inquiry arrives, your agent drafts the reply, you send it, the agent remembers what went out.

This is the use case the server exists to support. A customer inquiry lands in your inbox. You want your Subcore agent — which already knows your products, your CRM and your tone — to draft the reply. You send it yourself.

Subcore never contacts the customer. It returns text. Your workflow decides what happens to it. That is what makes this the agent used as a brain rather than as a channel.

The walkthrough

An inquiry arrives in your inbox

Your own mail tooling has it. Subcore is not on that path and does not need to be.

Find the conversation with `list_sessions`

If you already keep a mapping from your own thread — a ticket id, a mail thread — to the sid an earlier turn returned, use it and skip to the next step. That mapping is the only thing that reliably identifies this customer's history.

Without one, list_sessions shows what your key can reach, most recently active first:

{
  "core": "support-agent",
  "channel": "email",
  "runType": "production",
  "from": "2026-08-01T00:00:00Z",
  "limit": 25
}

list_sessions has no customer filter. core, channel, runType and the from/to window all narrow the list, but from is a time bound, not an identity, and nothing in the arguments says who was on the other end. The result spans your whole organization, so a sid chosen by eye can be someone else's conversation. Read it with get_session and confirm it is the right one before acting on it — then store the mapping, so the next inquiry does not depend on a guess.

get_session on that sid reads the conversation in full.

Get the agent's reply with `<channel>_send_message`

{
  "core": "support-agent",
  "from": "ada@example.com",
  "subject": "Where is my order?",
  "body": "My order has not arrived yet — can you check on it?"
}

No sessionId, because this is a new thread. The agent runs the inquiry with its real instructions, tools and CRM lookup, and returns what it would say.

The response carries the reply text and the sessionId it minted. Store that id against the thread. Every later turn on this thread passes it back.

Send it with your own tools

Read the draft. Edit it if you want to. Send it through your own email client, help desk or whatever you already use.

This step is yours entirely. Subcore has no part in it, which is exactly the point.

Record what you actually sent with `record_sent_reply`

{
  "core": "support-agent",
  "sessionId": "the id from step 3",
  "text": "the exact text the customer received"
}

Why step 5 matters

Skip it and two things go quietly wrong.

The agent's memory holds the wrong text. If you edited the draft before sending, session memory still contains the agent's version. The next turn on this thread reasons from a reply the customer never read, and the drift compounds over a long thread.

Telemetry does not know anything went out. Subcore did not send it, so without being told, the record of the conversation ends at a draft.

record_sent_reply fixes both: memory matches reality, and the session carries a reply.recorded event.

The tool only exists when the deployment runs kit 0.17.6 or later, which is when the record door was added. On an older deployment the tool is absent from the list. Steps 1 through 4 work regardless; you just lose the correction.

Continuing the thread

The customer replies. You pass the stored sessionId this time:

{
  "core": "support-agent",
  "sessionId": "the id from step 3",
  "from": "ada@example.com",
  "body": "Thanks — it still has not arrived though."
}

The agent has the whole history, because the history is every event under that id. You send nothing but the new message.

See session semantics for the rules, and why passing an id you were not given is the one mistake worth guarding against.

What this is not

This is not takeover. The agent is not replying to your customer; you are. There is no tool that claims a live conversation and answers on a real channel, and the two doors that would place a call or send a text (/outbound and /sms/send) are excluded from the tool list by path.

If takeover is ever offered over MCP it will arrive as a separately named, separately enabled tool set. It will not be something you get by turning on testing and telemetry.

On this page