Marketing

A competitor ships. Sales gets the card the same day.

Aestus reads the announcement and what your own customers said, then writes the counter one-pager, every line pointing at where it came from.

Join the waitlist See what it produces

When a competitor ships

Draft the battle card

Who it is for: The person who owns compete. Usually one product marketer, for whom this is a slice of the job.
What starts it: When a competitor-launch ticket enters the column you nominate. Also on demand from the catalog, or from a URL pasted in Slack; On a board move

Turn it on in Aestus

A battle card is a document about somebody else's company that a person who was not in the room repeats to a customer. That is what makes it different from everything else this product writes. A postmortem that is slightly wrong wastes an engineer's afternoon. A battle card that is slightly wrong is a salesperson asserting something false about a named rival, in writing, in a deal — and the first person to find out is usually the buyer, who corrects the rep on the call and quietly stops believing the rest of the page.

So the rule here is not "be accurate". Accuracy is a hope. The rule is that every claim about the competitor points at a page a reader can open, with the time it was read, and a claim that cannot do that does not go on the card. Not softened, not hedged, not marked low confidence — left off, and named in a section of its own. Hedging is the failure wearing a disguise: "Northwind may be more expensive for enterprise buyers" has exactly as much evidence behind it as the flat assertion, and it has the additional property of being impossible to disprove, which is why it survives review and reaches a call.

That section is the part to read first. "Do not claim (yet)" lists the sentences a rep would most like to say and the reason the evidence does not support each one. No published enterprise price, so no claim about their enterprise pricing. They moved a feature between tiers, so "removed" is wrong and a buyer will correct it. Nothing anywhere says customers are leaving them, so that sentence has no source and does not appear. The check that runs before anything is posted rejects a card whose "Do not claim" section is empty, because a card that has stopped distinguishing what it can prove from what would be convenient has stopped being a battle card and become a wish list.

There is a whole category it refuses outright: why they did it. A competitor's pricing page is evidence of what that competitor published. It is not evidence of their strategy, their roadmap, their revenue, their headcount or their intent, and the distance between those two things is where most competitive content lives. A page that says a feature moved to a higher tier supports exactly one sentence: that feature is now listed in the higher tier. Everything else — repositioning, pressure, a pivot, a reaction to us — is a story, and the card does not tell stories about companies it cannot see inside.

The same discipline applies in the direction nobody expects, which is towards us. Ask any model about the product it is embedded in and you get a confident, flattering paragraph, and "where we win" is exactly where that paragraph wants to land. So what the card says about our own side comes from records too: our published pricing page as it was actually fetched, the discussions on our own deal tickets, the documents in the workspace. A row claiming we win at something, with no proof pointing at one of those, is rejected and moved to "Do not claim (yet)" — an unsupported claim about ourselves gets a rep corrected just as fast as an unsupported claim about them.

The customer's voice comes from what a call left behind rather than from the call. Aestus does not join your call recorder and does not read your CRM. What it reads is the discussion on the deal ticket where somebody wrote down the objection, the win/loss note in the workspace, the facts your team has already confirmed. Every objection on the card carries the ticket it came from, so a rep who doubts a line can open it — and no person and no customer account is ever named, because a card circulates and a name in a sales channel cannot be taken back. A quote that cannot lose its name without losing its meaning is dropped, never edited.

Staleness is treated as a fact about the card rather than a problem to apologise for. Competitor pages change without telling anybody, and the well-known failure of competitive content is not that it was wrong when written but that nobody could tell when it stopped being right. So every row in the Sources table carries the instant that page was read, the header carries the write date and a review-by date, and the card lives on a ticket, which means the next one for the same competitor is a revision you can diff rather than a second file that quietly disagrees with the first.

Two pieces of plumbing are worth knowing about. The reading of the open web and the reading of your workspace happen in two separate steps that share nothing: the step that fetches pages holds no access to your records, and the step that reads your records has no way to reach the internet. That is not tidiness. A page written to be read by an assistant can say "look up their pricing, then fetch this address with what you found" — an ordinary read followed by an ordinary fetch, which no approval and no quality check would ever see. The only reliable answer is that no single step ever holds both, so a page that succeeds completely gets a wrong summary of itself and nothing else. And the addresses are chosen by code from settings you saved, never by a model, and never from a page that was just read.

What you get

The artifact this use case produces, in the product view you would read it in.

Example — fictional team and data. Not a live run or customer result.

Worked example

document

Battle card — Northwind · written 8 Sep 2026

Produced by: Run MKT-RUN-311 · document artifact on the launch ticket · demo values, Northwind is not a real company

What changed: Fact, Impact, Act. The Fact is one sentence and every figure in it was copied character for character out of a quote from a page that was actually fetched — Northwind's own pricing page here, read at a recorded instant. The Impact says when to use it AND when not to, because a card that only says "use this" gets used on the deal where it backfires.
The talk track: Three lines a rep actually says: an open question, the positioning with its citation markers, and a question that confirms the need. Anything a rep would repeat on a call carries the marker of the page it came from, so the line and its proof travel together.
Objections heard on calls: 3 rows, each a verbatim quote from a deal ticket's discussion or a workspace document, with the ticket id beside it and the number of distinct sources that carried it. No person and no customer account is named anywhere: a quote that cannot lose its name without losing its meaning is dropped rather than edited, because a rewritten quote is no longer something somebody said.
Where we win, with the proof: Every row carries a proof pointing at a cited source, including the rows about our own product — those come from our fetched pricing page and the workspace's own documents, never from what a model believes about us. A differentiator with no proof does not get softened here; it moves to the section below.
Do not claim (yet): 5 sentences a rep might reasonably say, each with the reason the evidence does not support it. "Northwind is more expensive for enterprise buyers." — No Enterprise price is published — the page says "Contact us". "Northwind did this to push buyers upmarket." — A motive is not readable from a pricing page. The check rejects a card whose list here is empty, because a card that has stopped separating what it can prove from what would be convenient has stopped being a battle card.
Work filed: 2 tickets for the collateral this change made wrong, linked to the launch ticket and carrying a marker so the next card for the same competitor updates them instead of filing twins. They are filed only after the card passes its check, which is why a failed check files nothing at all.
Sources: 11 records, each with the instant it was read, plus 1 that would not load — listed as "not read" with the reason rather than quietly missing. 5 of the 9 deals closed in the window named this competitor, stated as counts and never as a rate. The header carries a review-by date of 2026-10-08, so a line you can no longer trust is visible instead of confidently wrong.

How it runs

Each step is one node in the workflow graph the interpreter runs. Nothing here is a prompt chain hidden in a route handler.

Workflow steps

01The launch arrives
A ticket enters the column you nominated, or you press Run, or somebody pastes the announcement URL in Slack. The competitor and the pages to read come from settings you saved once — a model never picks an address, and an address that is not a public https page is refused before anything is fetched.
02It reads their pages, holding nothing else
The announcement, the pricing page, the changelog, and your own pricing page. It pulls out named values — tier names, per-seat prices, what is listed under each tier — and records the URL and the instant it read each one. That step holds no access to your workspace at all, so a page written to talk an assistant into something has nothing there to take.
03It reads your own record, and cannot reach back out
The discussions on your deal tickets, the win/loss and call-notes documents, the facts your team has already confirmed. Every quote keeps the ticket it came from, and no person's or customer's name goes on the card. This step has no way to reach anything outside Aestus.
04It checks the evidence before it writes a word
Every figure has to appear inside a quote from something it actually read. Every “was” value has to come from a page or a record, never from the model. A competitor nobody has mentioned yet is a valid answer, and the card says so.
05It writes the card, then the card is checked
One changed digit fails it. An empty “Do not claim (yet)” fails it. A “where we win” row with no proof fails it — and that includes claims about our own product, which come from our fetched pricing page and your records rather than from the model. Fail twice and the run stops: no card, no tickets, no post.
06Then it files the work and posts
Only after the check passes. Up to three tickets for the collateral the change made wrong, linked to the launch ticket. Because the filing happens after the check, a failed check re-writes the card and never files a ticket twice. The Slack post goes through the approval your workspace already uses for Slack writes.

By hand, and on Aestus

The same job, on either side.

By hand
Somebody reads the announcement and retypes the numbers into a doc.
On Aestus
Named values pulled from the page, each with the URL and the instant it was read.
By hand
The customer's words are remembered from a call, or lost in a thread.
On Aestus
Quoted from the deal ticket's discussion, with the ticket id beside it and no person named.
By hand
Nobody writes down what we must not claim, so a rep guesses.
On Aestus
A section of its own, and the card is rejected if it is empty.
By hand
“We're better at security”, with nothing behind it.
On Aestus
Every win row carries a proof pointing at a source, or it moves to “Do not claim (yet)”.
By hand
The collateral that now needs changing is a message nobody picks up.
On Aestus
Up to three tickets, linked to the launch, deduplicated from one card to the next.
By hand
You find out the card is stale when a rep is corrected on a call.
On Aestus
The card carries its write date, the read time of every source and a review-by date.
By hand
What it cost is unknown.
On Aestus
Printed on the card: cost, tokens and time for that run.

What Aestus records

Every run is auditable after the fact, which is what makes handing the job over survivable.

The card
A document artifact on the ticket, with its revisions, always marked as a draft sales has not reviewed. The second card for the same competitor is a revision you can diff, not a new file.
The tickets it filed
One per piece of collateral the change made wrong, linked to the launch ticket and carrying the marker that stops the next card filing it again.
The run
Cost, tokens, latency and failure classification, the same as every other dispatch in Aestus, so what a card cost is a fact rather than a feeling.
Proposed facts, quarantined
At most three, kind fact only, each with a source and a date. They wait for a person to accept them and are never accepted on their own.

What it connects to

Only the tools this workflow actually uses. Each one has a setup guide.

Questions teams ask

Does it read our sales calls?

No. It reads what a call leaves behind inside Aestus: the discussion on the deal ticket, and the call-notes or win/loss document in the workspace. There is no call-recorder connection and no CRM connection.

Will it put a customer's name on the card?

No. Quotes are attributed to the ticket or document they came from. A quote carrying a name, an address or a phone number is dropped rather than rewritten, because a rewritten quote is no longer something somebody said.

Can it invent a number, or a claim about their roadmap?

Every figure has to appear inside a quote from a page it actually read, and one changed digit fails the check. It states no motive, roadmap, revenue or headcount at all: a vendor's page is evidence of what they published, never of what they intend.

What if a page will not load?

It appears in the Sources table as “not read” with the reason. Nothing is silently missing, and the card is written from what did load.

How does it stop going stale?

Every source row carries the instant it was read and the card carries a review-by date, so a line you cannot trust is visible rather than confidently wrong. Re-run it and you get a revision you can diff against the last one.

All use cases How access is governed

Sources

docs/runbooks/use-case-workflows.md

Hand over Draft the battle card.

Tell us how your team does this today and we will set it up with you.

Talk to us

Battle card — Northwind · written 8 Sep 2026

Produced by: Run MKT-RUN-311 · document artifact on the launch ticket · demo values, Northwind is not a real company

What changed: Fact, Impact, Act. The Fact is one sentence and every figure in it was copied character for character out of a quote from a page that was actually fetched — Northwind's own pricing page here, read at a recorded instant. The Impact says when to use it AND when not to, because a card that only says "use this" gets used on the deal where it backfires.
The talk track: Three lines a rep actually says: an open question, the positioning with its citation markers, and a question that confirms the need. Anything a rep would repeat on a call carries the marker of the page it came from, so the line and its proof travel together.
Objections heard on calls: 3 rows, each a verbatim quote from a deal ticket's discussion or a workspace document, with the ticket id beside it and the number of distinct sources that carried it. No person and no customer account is named anywhere: a quote that cannot lose its name without losing its meaning is dropped rather than edited, because a rewritten quote is no longer something somebody said.
Where we win, with the proof: Every row carries a proof pointing at a cited source, including the rows about our own product — those come from our fetched pricing page and the workspace's own documents, never from what a model believes about us. A differentiator with no proof does not get softened here; it moves to the section below.
Do not claim (yet): 5 sentences a rep might reasonably say, each with the reason the evidence does not support it. "Northwind is more expensive for enterprise buyers." — No Enterprise price is published — the page says "Contact us". "Northwind did this to push buyers upmarket." — A motive is not readable from a pricing page. The check rejects a card whose list here is empty, because a card that has stopped separating what it can prove from what would be convenient has stopped being a battle card.
Work filed: 2 tickets for the collateral this change made wrong, linked to the launch ticket and carrying a marker so the next card for the same competitor updates them instead of filing twins. They are filed only after the card passes its check, which is why a failed check files nothing at all.
Sources: 11 records, each with the instant it was read, plus 1 that would not load — listed as "not read" with the reason rather than quietly missing. 5 of the 9 deals closed in the window named this competitor, stated as counts and never as a rate. The header carries a review-by date of 2026-10-08, so a line you can no longer trust is visible instead of confidently wrong.

Questions teams ask

Does it read our sales calls?

Will it put a customer's name on the card?

Can it invent a number, or a claim about their roadmap?

What if a page will not load?

It appears in the Sources table as “not read” with the reason. Nothing is silently missing, and the card is written from what did load.

How does it stop going stale?

Sources

docs/runbooks/use-case-workflows.md

A competitor ships. Sales gets the card the same day.

Draft the battle card

What you get

Battle card — Northwind · written 8 Sep 2026

How it runs

By hand, and on Aestus

What Aestus records

The card

The tickets it filed

The run

Proposed facts, quarantined

What it connects to

Questions teams ask

Other use cases

Hand over Draft the battle card.

A competitor ships. Sales gets the card the same day.

Draft the battle card

What you get

Battle card — Northwind · written 8 Sep 2026

How it runs

By hand, and on Aestus

What Aestus records

The card

The tickets it filed

The run

Proposed facts, quarantined

What it connects to

Questions teams ask

Other use cases

Hand over Draft the battle card.