Commander’s Intent

Here is a ticket a coding agent might pick up. It's invented for this post, and it's written the way most tickets are:

Add a 14-day free trial to the Team plan.
Require a credit card at signup.

Halfway through, the agent finds something the ticket didn't mention. A fair share of Team signups come through a partner marketplace, where the partner collects payment and the product never sees a card. The ticket says to require one. The agent can block marketplace signups from the trial, quietly skip the card check for them, or stop and ask. All three are defensible readings of the ticket, and the ticket gives no way to choose.

Here is the same ticket written a second way:

Add a 14-day free trial to the Team plan.
Require a credit card at signup.

Purpose:    cut repeat trial signups; finance traced most of
            last quarter's trial abuse to throwaway accounts.
End state:  repeat signups drop, and paid conversion holds.
Not settled: whether marketplace signups get a trial at all.
            Pricing has it pending.

Now the agent knows what the card is for. It's there to tie each trial to a paying identity, and a marketplace account already has one through the partner. The agent also knows the question it can't answer for itself is pending with someone else. So it builds the trial for direct signups, leaves the marketplace path alone, and flags the open decision.

The second version is the same instruction with the reason attached. Armies have a name for that attachment.

Commander's intent is a short statement, attached to an order, of the operation's purpose and the end state it is meant to reach, so that the people carrying out the order can make sensible decisions when the plan no longer fits the situation in front of them.

What the doctrine says

The U.S. Army's current statement of the idea is ADP 6-0, Command and Control, reissued in July 2026. It defines commander's intent, borrowing the joint definition, as "a clear and concise expression of the purpose of an operation and the desired objectives and military end state." An intent statement, the manual says, "includes the operation's purpose, key tasks, and conditions that define the end state."

The point of writing it down is what happens later. "In execution," the manual continues, "the commander's intent guides initiative as subordinates make decisions and take action when unforeseen opportunities arise or when countering threats." The orders that go with it are meant to stay light. Mission orders "emphasize to subordinates the results to be attained, not how they are to achieve them."

One of the manual's historical examples is a letter. In April 1864, Lieutenant General Ulysses S. Grant wrote to Major General William T. Sherman describing his part in that year's campaign: move against Joseph Johnston's army, break it up, and get as far into the enemy's country as he could. Then Grant added the sentence the Army still quotes: "I do not propose to lay down for you a plan of campaign, but simply to lay down the work it is desirable to have done and leave you free to execute it in your own way." Sherman's reply showed he had understood the intent, not just the assignment. He wrote that he would "not let side issues draw me off from your main plan."

The Army codified the term mission command in the 2003 edition of FM 6-0, but the practice is much older than the manual. Grant didn't need the vocabulary to know that a subordinate running his own army, far from Grant's headquarters, needed the purpose more than the plan.

Discipline first, then initiative

Intent isn't permission to improvise. The doctrine is precise about this, and its definition of disciplined initiative is worth reading slowly: "Simply put, disciplined initiative is when subordinates have the discipline to follow their orders and adhere to the plan until they realize that their orders and the plan are no longer suitable for the situation in which they find themselves."

Two failures sit on either side of that sentence, and coding agents show both. An agent without intent can follow the ticket to the letter after the ticket has stopped making sense: it requires a card the marketplace flow can never collect, and the marketplace signups break. Or it can improvise without any guide: it decides on its own that marketplace users don't get trials, and a pricing question nobody has answered gets answered in a pull request. Both agents did what agents do with an order and no reason. One obeyed. The other guessed.

The doctrine's guidance for the moment between those failures is plain. "If time permits, subordinates attempt to communicate their new situation and recommended course of action to their commander." And when they do act, they weigh "whether the action will further the higher commander's intent." That's the second version of the ticket. The agent acts where the intent is clear, and reports where the intent itself is still being decided.

Intent nests, and tickets don't

One line in ADP 6-0 explains why this is harder in a product organization than it looks: "Each commander's intent nests within the commander's intent two levels up." A platoon's purpose makes sense inside the company's, which makes sense inside the battalion's.

Product work nests the same way, across the stages of the product development lifecycle. The homepage traces one example through all seven. The company's ideal customer and positioning (DOC-118, in Confluence) frame a goal for the quarter (OKR-Q4, in Slack), which sets up a roadmap item (RM-3, Checkout v2, in Jira). That depends on a pricing decision taken up during refinement (D-241, seat-based pricing, in Slack), which shapes a spec (CHK-412, in Jira), which becomes a merge request (!1182, in GitLab), which feeds a launch (DOC-131, in Confluence). The intent behind the merge request lives in everything upstream of it.

The ticket a coding agent receives sits near the bottom of that chain, and it usually carries the task and none of the nesting. Coding agents sped up Build, one stage of seven. The intent they need was set in the other six, in Slack threads, spec comments and meetings, and a ticket is a poor container for it. The faster the agent, the more decisions it makes per hour without the reasons, and the more often a guess becomes the shipped answer.

Where Brief fits: intent that travels

Brief is the product strategy agent: "Everyone, and every agent, working from shared context." In Army terms, that's an intent system. As the homepage puts it, Brief "works across all product stages, not just Build. It captures decisions where they happen, connects them into one graph, and acts on them." Here is what each part does for the problem in this post.

Decisions carry their reasons. A decision recorded in Brief shows what was decided and why. When someone records one directly in the app, What was decided? and Why? are both required. The why is the purpose line of the second ticket: what the decision is for, which is what lets someone apply it to a case nobody anticipated. A decision can also carry a Re-evaluate when condition, the decision's own statement of the situation in which it stops fitting.

Decisions are captured where the intent is set. The intent behind a ticket is formed in the stages before Build, so that's where Brief picks it up. Brief reads decisions from Slack, Jira, Confluence and GitLab, self-hosted included. In Slack, /propose turns an open question into a proposal, and when you mention @Brief in a thread, Brief may propose a structured decision from the conversation for you to confirm or edit. The pricing question in the second ticket is a proposal like that, with a status, and an owner once someone is assigned.

Agents read the intent before they act. Brief's agent setup has coding agents call brief_get_onboarding_context at the start of every session, which loads the team's recent decisions along with its personas, velocity, recent work and customer insights. Before writing code, agents connected over MCP ask Brief with brief_ask. On the homepage, an agent asked to add per-seat pricing learns that D-241 is still pending, holds the change, and flags a related security review it found. That's the doctrine's instruction carried out by software: act within the intent where it's settled, and report the new situation where it isn't.

A deviation can be checked against the intent. When an agent or an engineer wants to depart from the plan, brief ask --mode check checks the proposed change against existing decisions and flags conflicts. That's the doctrine's test, "whether the action will further the higher commander's intent," run before the change ships.

Everyone reads the same intent. The homepage's phrase for this is "no AI silos between product and engineering": coding agents in engineering and Claude in product read the same decisions. People do too. On the homepage, an engineer asks on a Jira ticket why it can't ship yet, and Brief answers there with the three decisions that apply, including the pending one. Understanding intent two levels up stops depending on whether you were in the meeting.

Brief doesn't write the intent. The manual is firm that commanders "develop their intent statement personally," and the product equivalent holds: someone with the authority has to decide what the trial is for and say why. What Brief changes is how far that statement travels once it exists. A reason given once in a Slack thread reaches the agent writing the code, the engineer reading the ticket, and the product lead drafting the launch, without anyone retyping it into each of their tools.

What would your coding agents do differently tomorrow if every task they picked up came with the reason it exists?

Objections