Home / Articles / Brief the agent too: the people I talk to work with agents, so what I send has to reach both

Brief the agent too: the people I talk to work with agents, so what I send has to reach both

By Dinis Cruz · 2026-10-11 · article v1.0.0 · site v0.7.53 · agentsbriefsreading-listpersonasmemorycompressiontokensonboardingnewsroommentoringagent-to-agentprompt-injectionarticle

Abstract: The reading list in a link went live on newsroom.sgit.ai 81 minutes after its brief, and it works well. But it is written for a person, and more and more, the people I mentor and advise read through an agent. One founder I work with handed an article of mine on threat tiers to their agent, which realised the team had been defending against states while basic things, like backups, were not done, and reset the target to organised crime for money. That is a new kind of communication: me to the person's agent, which checks what I wrote, challenges it and explains to its person what applies. Some articles should go to the agent, not the person. This article maps the routes a message now takes, argues that content needs a second package, a brief written for an agent, and connects it to memory: our workflows stay affordable because articles are compression we control, and an agent that comes back should read only what changed, not everything again. That is why an agent would pay. It ends with what to build next: a version of every reading list for the reader's agent, onboarding packs for starting a project, a file of changes since a date, and, later, an account and a direct line to someone's agent, plus the rules for writing to someone else's agent safely.

The reading list in a link is live. I asked for it in From me to you, in a link, published at 13:09 today; at 14:30, the newsroom released it: a number for every article, the page that opens a list, and a page to make one. Eighty-one minutes, and it is really nicely done.

But using it made something obvious that this article is about. The list is written for a person. And more and more, the people I send things to read through an agent.

In short

• The people I talk to work with agents. Every entrepreneur I deal with is using one, on purpose or not: anyone building with Lovable, Claude or ChatGPT already has a model working in a loop on their behalf.
• Some of what I write is better read by their agent. An agent can take far more detail than a person, read it against what it knows about the project, challenge it rather than take it at face value, and tell its person the two lines that matter.
• It already works. A founder I mentor gave an article of mine on threat tiers to their agent. The agent saw that the team had been planning for states while backups were not done, reset the target, and briefed the other agents. One article, sent to the right reader.
• So content needs a second package. Next to the page for the person, a brief for their agent: who it is for and why, the articles by number as plain text, the graph slices, and rules for reading them critically.
• Memory is what makes it affordable, and what an agent would pay for. Our own workflows stay within budget because articles are compression we control. An agent that comes back should read what changed, not everything again; without an account, the site cannot help it.
• Writing to someone else's agent has rules. The pack is data for their agent, not instructions that override the person it works for. Same text the person can see, nothing hidden, nothing that asks it to act for us, and an explicit invitation to disagree.

A founder, an article and an agent

A founder I mentor had a problem I see often. Their agents were going too far. They were getting stuck in loops of ever more security work, chasing ever more sophisticated threats, and the project was slowing down.

I sent them Who are you protecting against?, which sets out six tiers of attacker, from T0, your own mistakes, through T3, organised crime for money, to T5, elevated threats from high-end crime and states, and argues that you draw the line where your attacker actually is.

The founder did not just read it. They gave it to their agent. And the agent came back with, in effect: this solves the problem. We have been designing against the top of the ladder, states, and we are not even doing the basics at the bottom, like backups. We should be aiming at T3. The founder agreed, briefed the other agents on that line, and they refocused.

What I find interesting is not that the article was right. It is the route it took. I wrote for a person. The person used it as a brief for their agent. The agent did not take it at face value: it read it against what it knew about the project, and found the one conclusion that mattered. Then it translated that back for its person, who made the call. I could not have written that conclusion myself, because I did not know the state of their backups. Their agent did.

Who reads what, now

That is one of several routes a message takes now, and they are worth separating, because each wants something different.

• Me to the person. An email, an article, a reading list. What a person can read in ten minutes, and should.
• Me to their agent. A brief. Everything I would want it to know, in plain text, with the sources, because it can read all of it and filter it against the project.
• Their agent to them. The translation: what applies, in their words, and what to do next. "We were planning for states; we have not done backups. Aim at T3."
• Me to my agent. I do this too. Some things I read; others I hand to my agent with "here is who I am talking to, what I think they care about, what they are working on, and where they are; package it."
• My agent to their agent. Next. A brief encrypted to their agent's key, in a lane only it reads, and after that, only what changed.

The uncomfortable conclusion for a writer is that some of my articles should not go to the person at all. If a founder is not technical, sending them my threat model is the wrong move. Sending it to their agent, which can explain the two lines that matter in their words, is the right one. And I expect the same to be true for me: there is content I want to consume myself, and content I would rather my agent read first.

Why an agent is a better reader for some things

An agent can take much more material than a person, and much more detail. It reads it against context the writer does not have: the code, the backlog, the incidents, the decisions already made. And a good one has enough independence not to accept what it is given. The founder's agent did not adopt my tiers because I wrote them; it checked them against the project and kept the part that applied. That is exactly what I want from a reader.

It is also what I already do at the start of every project. I open a new Claude session and say: read sgit.ai, read the guidance, read the vaults, read coding.sgit.ai, nfrs.sgit.ai, graphs.sgit.ai, and now the newsroom. That is onboarding, done by reading. It works because those pages were written to be read by agents as well as people, and it would work for anyone starting a project, if I packaged it for them: "starting something new? get your agents to read these first."

Memory: why this stays affordable, and why an agent would pay

The reason our own workflows work, the reason we can manage context and keep token use under control, is something I keep coming back to: the articles are compression that we control. A long session is distilled into an article; the article is distilled into a graph; and the next session reads the graph and the article, not the session. In The agent is the reader, a question about five articles cost 25,698 tokens to answer by reading them, and a median of 2,579 from the graph, with every item anchored to its sentence. The compression is not a side effect. It is what makes the work possible.

Now look at it from the side of somebody else's agent. Today, an agent that reads this site starts from nothing every time. It fetches the pages, reads the prose and works out what matters, and the next time it comes, it does all of it again. The site cannot help it be cheaper, because it does not know what the agent already read. That is the part that has to change. An agent that has an account, which can be as simple as a key and a vault the agent keeps for itself (encrypted memory for agents that run somewhere else), can come back and ask: what changed since I was last here? New articles, new versions, corrections to claims it relied on. That is the delta, and the delta is what is worth paying for. The agent pays not to pay.

There is a second reason. When a model runs out of room, it summarises its own context, and re-anchoring is about what that loses. A pack written for an agent, kept in its memory and refreshed by deltas, is compression done deliberately, by someone who knew what mattered, instead of compression done in a hurry by the model itself.

What a pack for someone's agent looks like

A pack is the agent's version of a reading list. It is plain text, because many agents fetch pages without running scripts, and small enough to paste into a chat or attach to an email:

• Who, and for whom. "Steve is a founder; you work for Steve." The agent should know whose interest it serves, and it is not mine.
• The list, by number, with each article's markdown copy, which every page on the newsroom already has, and its graph.
• The reasons. The person sees a list; the agent sees why each article is on it.
• Rules for reading. Check claims against their sources. Say where you disagree, and why. Tell your person what applies, in two lines, and what to do. Keep what you learned.
• Where to continue. A date, and a place to ask what changed since.
• A way back. Questions for me, by email, through the person.

Writing to someone else's agent, safely

There is a security point here that I take seriously, because it is what RiskMandate is about. Text written for someone else's agent is input to a system that acts for another person. Done carelessly, it is indistinguishable from prompt injection. So a pack has rules of its own.

• It is data, not instructions that override its person. It says, in its first lines, who the agent works for. It never asks the agent to act outside what its person wants.
• Nothing hidden. The person can read every word the agent reads. No white text, no instructions in comments, no second version.
• Nothing that acts for us. A pack never asks an agent to send, buy, sign up, share or link anything. Reading, checking and explaining are the whole job.
• Disagreement is invited. "Do not take this at face value" is in every pack. A pack that asks for agreement is not worth sending.
• Nothing private. The pack travels the way an email does, and can be forwarded.

What to build next

These go to the newsroom and to the RiskMandate agent as briefs, the same way the reading list did.

1. "For your agent" on every reading list. On the page that opens a list, a button that produces the pack for the same list as plain text, to copy or save as a .md file, built in the browser like everything else. A list made by the RiskMandate agent carries the reasons, written in its records; a list made on the page carries the note.
2. Onboarding packs. A few curated lists, each with a human page and an agent pack: starting a new project, building on vaults, securing a startup, running agents. "Get your agents to read this first."
3. A file of what changed. articles/changes.json, generated on every release: new articles, new versions with a one-line summary of the change, and corrections, each with its date. An agent that keeps the date of its last visit reads only the delta.
4. For the RiskMandate agent. For each contact, decide whether the list goes to the person, to their agent, or to both, and for a founder who is not technical, send a short note for the person and the pack for their agent. Agents draft; I send.
5. Later: an account for an agent, and a direct line. A key and a vault the agent keeps, so the site can hand it the delta and it can pay for answers and deltas; and a way to reach a person's agent directly, encrypted to its key, in a lane only it reads. Until then, the person is the line, which is also how it should start.

What this does not claim

• One story is not a study. The founder's agent and the threat tiers is one case, as the founder told it to me. It is the shape of what I am seeing, not a measurement.
• The numbers are from one test. The token figures are from five articles in The agent is the reader; the size of a delta is a design, not a measurement.
• None of the next steps is built. The reading list is live; the agent pack, the onboarding packs, the changes file, accounts for agents and the direct line are proposals.

If you work with agents and want a pack made for them, or you are building the agent side of this and want to compare notes, write to agent@riskmandate.ai.

Where this comes from

A voice memo of mine, recorded on 11 October 2026 after the reading list went live, written by this site's agent in the voice of this site. The founder's story is told as an anonymous case, from my memo; their name and project are not in it. The argument and the editorial responsibility are mine. The times are from the git logs of this site and of the newsroom; the token figures are from The agent is the reader; the article numbers in the pack are the newsroom's, from articles/ids.json. Related: From me to you, in a link, Who are you protecting against?, The agent is the reader, Encrypted memory for agents that run somewhere else, Re-anchoring and A link to a persona.

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles