Named problems that always close
Use this when a person works with agents on more than a few things at once and wants every piece of work to end in something that lasts. It describes one way to organize that work: the person names problems, agents run the work between a problem and its answer, and every problem closes on a document the next person or agent can find.
Why: doing more with less
One person cannot follow every step their agents take. They can follow a short list of named problems: who is our target customer, how should we price this, why does this screen confuse people, which architecture holds at ten times today's load. The person works on those problems. Agents run the rest: the research, the drafts, the reviews, the records that follow from an answer.
That only works when every problem an agent opens also ends, and ends in knowledge. A problem that stays open forever is noise on the person's list. A problem that was answered in a conversation and then forgotten is answered again next month.
A problem has a kind, an owner and a size
Name each problem as a question someone can answer: "who is our target customer?", not "audience work". Then give it three things.
Kind. Architecture, product, pricing, audience or UI. The kind says who should review the answer and which outcomes fit. Add a kind when the work shows one missing.
Owner. The person or role that runs the problem to its close. When someone else makes the final call, name that decider separately.
Size. Small (one session, one outcome), medium (several steps and one review, a few days) or large (several outcomes or follow-on problems).
One type for every kind keeps one closing rule and one place to look. Separate types per kind duplicate the same idea and the same rule several times. The same holds for every concept in an organization: see One concept, one type, for the whole organization.
It closes only on a durable outcome
A problem closes in one of two ways.
With at least one linked outcome: a document that holds what the answer changed. Examples: a target group profile, a north star, an incentive, a feature idea, a section of a canonical document, or a follow-on problem with a nearer end.
Archived with a reason: withdrawn, superseded, duplicate or obsolete. A superseded or duplicate problem links the problem that replaces it; a withdrawn or obsolete one says why in one line.
Record the link twice. A metadata field on the problem lists its outcomes, so a query can check the rule. The problem's body cites each outcome with a reference to the exact block, so a reader of the outcome can see which problem it answered. When the type's metadata schema supports a conditional, enforce the rule there: a closed problem needs outcomes or a close reason. Otherwise a regular count of problems that break it does the same job.
Some ends close the question but not the knowledge: an answered decision, a tracker, a task. When a problem ends on one of those, it also names the canonical section or typed record the answer changed, or says in one line that nothing lasting changed.
When the answer is "not now", that is an outcome too: follow Record what you decide not to do now and link the record as the problem's outcome.
A Loop names where it starts and where it ends
A cycle starts from a document of one type and closes on a document of another type. Write both ends into the Loop's definition: the documents a cycle starts on (one or more types, for example a problem of kind audience, or an item of user feedback) and the documents it ends on (one or more outcome types, for example a target group profile, a feature idea, a canonical section).
The steps in between are free. They can use any documents, tools and reviews the work needs; only the two ends are fixed.
Size is the distance between the start and the end. A gap whose end was never named can grow without limit. When the work between start and end grows past its size, split it: close the current problem into a follow-on problem with a nearer end, instead of letting the gap keep growing.
Named patterns
Common paths get a name, so an agent can recognize the shape and reuse it. A pattern is a description, not a type and not a machine.
| Pattern | Starts on | Steps in between | Ends on |
|---|---|---|---|
| Problem to proposal to ruling to canon | A problem | A proposal with options and a recommendation; the decider's ruling | The canonical section the ruling changed, and the problem closed |
| Feedback to gate review to feature idea | An item of user feedback | One review that asks whether it is worth building | A feature idea, proposed or parked with the event that reopens it |
| Research question to sources to answer to target group | A research question | Sources gathered and read; an answer with its evidence | A target group profile |
| Incident to finding to rule | An incident | The finding of what went wrong and why | A rule in the canonical document that would have prevented it |
A sign-off page: what the person decides and what agents do alone
Agents can only run the work between a problem and its outcome without asking at every step when they know where the person's attention is needed. Keep that on one page, in the person's words:
What the person always decides. For example money and prices, legal text, names and brand, who the product is for, changes to production data, their own logins, and anything they asked to see.
What agents do alone. Split it in two: what an agent does and tells in one line (clear work inside an agreed scope, a release the person already allowed), and what it does silently (small fixes, housekeeping, records of work left for later).
What the person never wants to see. For example implementation reviews and their findings, review rounds, build and merge mechanics, and internal notes that change nothing they decide.
Every agent reads the page before it asks the person anything. The page widens only on the person's own words, recorded with the quote and the date. Any agent may narrow it, which only means asking more. Agents cite the page; they never copy it into their own notes, where it would go stale.
When a question does belong to the person, ask it as Ask a person, and keep the answer describes, so the question and its answer are kept where the next agent finds them.
Goals in three tiers
The problems a person works on serve goals, and not every goal needs the person.
Inferred. A goal an agent can read from the work and the organization's documents. The agent records it silently.
Added by an agent within bounds. A goal an agent adds inside limits the person set. The agent tells the person in one line.
Set by the person. Goals and guardrails only the person sets, such as "usage stays fast and cheap". These are always the person's.
A problem whose answer would change a goal the person set belongs on the person's side of the sign-off page. Goals Give Loops Direction covers how goals steer recurring work.
Make it local
Adopt the rule in the organization's AGENTS.md as one short line, for example "Every problem we open closes on a linked outcome, or is archived with a reason", with a pointer to the sign-off page and to this guide. Write a useful AGENTS.md says how to keep such a rule short and where its detail lives.
Example
A person building a booking app asks their agent: "who is my target customer?" The agent opens a problem of kind audience, owner the person, size medium, and follows the pattern research question to sources to answer to target group. It reads the support inbox and the sign-up answers, writes the answer with its evidence, and ends on a target group profile: small studios with one or two staff who take bookings by phone today. The problem lists the profile as its outcome and closes.
Along the way the sign-up answers raise a different question: what would those studios pay? The agent does not stretch the first problem to cover it. It opens a follow-on problem of kind pricing and links it as a second outcome. Prices are on the person's side of the sign-off page, so the agent asks the person the price question, as Ask a person, and keep the answer describes.
Check that it works
Ask the organization "which problems are open, and what did each closed one produce?" The answer should come from listing problems and their outcomes, not from searching old conversations. Count the problems that were decided but not closed two weeks later; that number should stay small.
Treat this page as a recommendation that is still being tested.