What Context Actually Means
When we say an agent lacks context, we don't mean it needs the entire project handed to it before every task. That's not context - that's noise. Flooding an implementation with everything that's ever been decided doesn't help the agent. It buries the signal.
What an agent actually needs is the relevant slice. For this task, at this stage, what does the implementer need to know? What decisions upstream affect this work? What's been built adjacent to it that changes the constraints?
That's a different problem than storing project information. That's distillation on demand.
The Secretary distills.
What an agent actually needs is the relevant slice. For this task, at this stage, what does the implementer need to know? What decisions upstream affect this work? What's been built adjacent to it that changes the constraints?
That's a different problem than storing project information. That's distillation on demand.
The Secretary distills.
Where She Shows Up
The Secretary isn't a single step in the pipeline. She's a persistent role invoked across multiple stages - same role, different slice of the project each time.
- At task generation: Before tasks are written, the Secretary provides the scope layer. What's already been built? What decisions constrain this feature? What's the intent behind this part of the project? The task gets written with that understanding baked in, not bolted on as an afterthought.
- At implementation: The agent receives the task with the Secretary's relevant context already embedded. Not a project summary. The specific decisions and adjacent work that affect this task. The agent implements with the right constraints in view.
- At Judge review: Before the Judge evaluates the code, the Secretary briefs her. Here's what this task was for. Here's the decision that shaped the implementation approach. Here's how it connects to the three tasks before it. That context changes what "correct" means. Code that looks wrong in isolation can be exactly right in context. Code that looks right in isolation can be subtly wrong given what came before.
- At Teacher recording: When a learning gets captured, the Secretary provides the project scope. Is this a global lesson, a pattern that applies to all future projects? Or is it a project-specific edge case, shaped by decisions unique to this build? The distinction matters. A global lesson belongs in the permanent curriculum. A project-specific exception shouldn't pollute it.
- At Sheriff audit: Security context is often project-specific. Who are the users? What data is sensitive here? What authentication model was chosen and why? The Sheriff's rulebook is general. The Secretary makes it specific.
Why This Is Hard to Build
The easy version of the Secretary is a document. You write up the project spec, attach it to every task, call it context.
That's not what she does. And the gap between a spec attachment and actual context distillation is where most systems quietly fail.
A spec tells you what's planned. The Secretary knows what's been built... which is often different. Decisions get made mid-project. Constraints emerge that weren't in the original spec. Features get scoped differently once implementation starts. The living state of a project drifts from the planning document almost immediately.
The Secretary needs to track that drift. She needs to know not just what was decided, but when, and what changed it, and what that means for the task in front of her right now.
That's why she's the last piece. The other staff members operate at the task level - review this, record this, route this. The Secretary operates across the whole project timeline. She needs the project to have enough history to distill from. She needs the other staff to be running so she has their outputs to work with.
She's being built last because she has to be.
That's not what she does. And the gap between a spec attachment and actual context distillation is where most systems quietly fail.
A spec tells you what's planned. The Secretary knows what's been built... which is often different. Decisions get made mid-project. Constraints emerge that weren't in the original spec. Features get scoped differently once implementation starts. The living state of a project drifts from the planning document almost immediately.
The Secretary needs to track that drift. She needs to know not just what was decided, but when, and what changed it, and what that means for the task in front of her right now.
That's why she's the last piece. The other staff members operate at the task level - review this, record this, route this. The Secretary operates across the whole project timeline. She needs the project to have enough history to distill from. She needs the other staff to be running so she has their outputs to work with.
She's being built last because she has to be.
What She Changes
Without the Secretary, Quality Gates enforces standards at the task level. Each task gets reviewed against its own acceptance criteria, its own security requirements, its own implementation standards. That's better than nothing - significantly better. But it's still local.
With the Secretary, Quality Gates enforces standards at the project level. The Judge doesn't just ask "is this task correct" - she asks "is this task correct given everything that came before it." The Teacher doesn't just record what went wrong - she records whether it was a global lesson or a project-specific edge case. The Specialist doesn't just route by task complexity - she routes with project history in view.
The staff goes from reviewing tasks to reviewing work. There's a difference.
With the Secretary, Quality Gates enforces standards at the project level. The Judge doesn't just ask "is this task correct" - she asks "is this task correct given everything that came before it." The Teacher doesn't just record what went wrong - she records whether it was a global lesson or a project-specific edge case. The Specialist doesn't just route by task complexity - she routes with project history in view.
The staff goes from reviewing tasks to reviewing work. There's a difference.
The Prototype Approach
We're not building the Secretary from a spec. We're running a real project manually first - task by task, with a human playing the Secretary role to understand what she actually needs to capture and when.
That's deliberate. The Secretary's job is nuanced enough that building her from assumptions would produce something technically correct and practically useless. What does the Judge actually need to know before a review? What does the Teacher need to distinguish a global lesson from a local one? Those questions have answers, but the answers come from watching the process run, not from designing it in advance.
The prototype tells us what to build. Then we build it.
That's deliberate. The Secretary's job is nuanced enough that building her from assumptions would produce something technically correct and practically useless. What does the Judge actually need to know before a review? What does the Teacher need to distinguish a global lesson from a local one? Those questions have answers, but the answers come from watching the process run, not from designing it in advance.
The prototype tells us what to build. Then we build it.
Why She Completes the System
The Teacher prevents recurring mistakes. The Judge enforces quality. The Sheriff enforces security. The Specialist routes intelligently.
All of them are better with context. All of them have been operating without it.
The Secretary doesn't add a new concern to Quality Gates. She makes every existing concern more precise. More accurate. More aware of the specific project it's operating inside.
When she's running, a lesson the Teacher records will be correctly scoped. A review the Judge conducts will account for upstream decisions. A security audit the Sheriff performs will understand what's actually sensitive in this project. An assignment the Specialist makes will factor in what this project has revealed about task complexity so far.
That's what closed-loop looks like.
All of them are better with context. All of them have been operating without it.
The Secretary doesn't add a new concern to Quality Gates. She makes every existing concern more precise. More accurate. More aware of the specific project it's operating inside.
When she's running, a lesson the Teacher records will be correctly scoped. A review the Judge conducts will account for upstream decisions. A security audit the Sheriff performs will understand what's actually sensitive in this project. An assignment the Specialist makes will factor in what this project has revealed about task complexity so far.
That's what closed-loop looks like.
Where This Leaves Us
Quality Gates is a working system. The Teacher, Judge, Sheriff, and Specialist are deployed and producing results. The Warden dashboard shows everything in real time. The staff is on the job.
The Secretary is what makes the whole system aware of itself.
Once she's running, we'll have something worth sharing properly... not just as a set of concepts, but as a service. If you're a developer or agency doing AI-assisted builds, that's the conversation we want to have.
The Secretary is what makes the whole system aware of itself.
Once she's running, we'll have something worth sharing properly... not just as a set of concepts, but as a service. If you're a developer or agency doing AI-assisted builds, that's the conversation we want to have.
If you have questions on if AI is a good fit for your specific problem, reach out. We'll be happy to have a conversation with you and help you determine if AI can be beneficial for you.