Policies, Instructions and Knowledge
Standing context is everything agents read that is not the work itself: written once, applying to every piece of work afterward, whether or not anyone thinks to mention it. Taiga gives you three kinds, and putting something in the wrong one is the most common way to be surprised by what comes back.
Policies come first, in every sense. They are generated when the organization is created, they are always present, and everything produced is measured against them. The other two extend them.
The distinction is not arbitrary. Each answers a different question.
| Answers | Nature | |
|---|---|---|
| Policies | What are the rules? | Formal governance. Generated, confirmed by you, always present. |
| Instructions | What do the rules mean here? | Freeform extension of the policies. Often empty, and fine that way. |
| Knowledge | Where are the details? | Reference material, retrieved when relevant. |
Which one do I want?
Section titled “Which one do I want?”A rule that would be true of the next project too. Instructions or Policies, and the split is finer than preference versus obligation, because the generated policies already carry most engineering obligations. Ask instead: is this rule already there, in the generic form good governance uses? Your policies say error responses must be consistent; the instruction names the format. They say pagination follows consistent patterns; the instruction picks cursor or offset. They say coverage thresholds are defined per project; the instruction sets the number. Policies decide what must be true. Instructions decide what that means here.
A document that already exists and has the answers in it. Knowledge. An API contract, a data dictionary, a partner’s integration guide. You are not restating it, you are making it available.
A correction you have made more than twice in review. Instructions, without question. Correcting the output leaves the cause in place for every future run.
Everything narrows as it comes down
Section titled “Everything narrows as it comes down”Instructions and Knowledge exist at the organization, the team and the project. Each level adds to what is above it. Nothing at a lower level cancels a higher one, so the levels are places to be more specific, not places to disagree.
- Organization. The house style every team inherits.
- Team. That team’s domain, stack and standards, inherited by every project in it.
- Project. The specifics of this codebase. The narrowest layer.
Policies are set for the organization, because a rule that one team can opt out of is not doing the job a policy exists to do.
Write a thing as high as it is true and no higher. Too high and it constrains every project you ever create. Too low and it is a rule you will forget to repeat.
What arrives filled, and what starts empty
Section titled “What arrives filled, and what starts empty”Policies arrive generated from your onboarding answers, because an organization cannot start from a blank governance page. Filled in is not the same as chosen, which is exactly why Taiga asks you to read and confirm them. Policies covers the set.
Instructions and knowledge start empty at every level, and nothing is seeded behind you. Standing context that nobody chose is the worst kind: it shapes everything and no one remembers agreeing to it. An organization that runs on its confirmed policies alone is not behind on setup; instructions exist for the day a specific answer is worth writing down. Instructions covers how the three levels combine.
How this reaches an agent
Section titled “How this reaches an agent”None of it needs attaching to a piece of work. Policies and instructions are collected from every level and supplied with each run. Knowledge is searched, within the same levels, when the work calls for it. Either way you did not have to remember it, which is what makes it standing.
The one deliberate exception: an initiative can reference specific knowledge documents, which focuses the search on exactly those for that piece of work. Attaching is never required for material to be found; it is how you say which documents matter most here.
The practical consequence is that a change to your instructions changes the next run and every run after, without anyone remembering to apply it. That is the leverage, and it is also why a careless line at the organization level is expensive.
For how to write these so they change the output rather than just existing, see write intake agents can act on.
Did you find what you needed?
