Designing a Blueprint Your Team Can Actually Maintain
In short
A blueprint holds the persona, the knowledge scopes, the tasks, and the output contracts an agent runs under. Keep instructions specific and few, put structure in output contracts rather than prose, and add configuration only when a real run has failed without it.
What a blueprint actually holds
Persona, knowledge scopes, tasks, and output contracts. That is the whole surface. Everything else — the individual documents, the conversation, the results — belongs to a case or a run.
The separation matters because a blueprint is reused across many cases. Anything that varies per case does not belong in it.
Fewer, sharper instructions
Long instruction blocks fail in a predictable way: rules contradict each other, and nobody can tell which one produced a bad answer. Prefer a small number of specific instructions over a comprehensive style guide.
If an instruction has never changed an output, it is not an instruction — it is decoration. Remove it.
Put structure in the output contract
Asking for a specific shape in prose is unreliable. Declaring it as an output contract is not — the contract is checked before the answer is returned, so a malformed result is caught rather than shipped.
This also makes downstream integration stable. Consumers can rely on the shape without parsing prose.
Add configuration only after a failure
Every configuration concept in Inteleto is gated behind a trigger: you see it when a run has actually needed it. This is deliberate. Configuration added speculatively is configuration nobody understands six months later.
Start with the smallest blueprint that produces a correct run, then let the failures tell you what to add.