Instructions, Knowledge, Policies and Specs
Taiga gives you four places to write things down. They look alike, they are all read by agents, and putting something in the wrong one is the most common way to be surprised by what comes back.
The distinction is not arbitrary. Each answers a different question.
| Answers | Nature | |
|---|---|---|
| Spec | What are we building? | The work itself. Specific to one project. |
| Instructions | How do we build? | Standing house style. Applies to everything. |
| Policies | What are the rules? | Formal governance. Applies to everything. |
| Knowledge | Where are the details? | Reference material, retrieved when relevant. |
Three of the four are standing context: written once, applying to everything afterward. The Spec is the work. That difference is why the other three are worth setting up carefully and rarely, while a spec is written per project.
Which one do I want?
Section titled “Which one do I want?”A requirement for this product. Spec. It describes this thing and only this thing.
A rule that would be true of the next project too. Instructions or Policies. Ask whether it is a preference or an obligation: “we default to Postgres” is house style, “personal data never leaves the EU” is a rule.
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 inherits what is above it and narrows it.
- 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.
Nothing is filled in for you
Section titled “Nothing is filled in for you”Instructions are empty by default at every level. There is a template you can start from, but you have to ask for it, and nothing is seeded behind you.
This is deliberate. Standing context that nobody chose is the worst kind: it shapes everything and no one remembers agreeing to it.
The exception is the material Taiga generates during onboarding, which is proposed rather than assumed. Policies covers what that produces and why it asks you to confirm it.
How this reaches an agent
Section titled “How this reaches an agent”You do not attach any of it to a piece of work. Standing context is resolved from the levels above and supplied with every run, which is what makes it standing.
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.