n our experience, most agent failures weren’t model issues but intent drift. The agent starts with a narrow goal, then gradually “helpfully” expands scope because nothing re-asserts intent between steps.
What worked for us was making intent explicit per step and treating it as a constraint, not just context. Each step declares what it’s allowed to do, which tools it can touch, and what kind of output is valid. After the step finishes, that authority is torn down.
The system feels less flexible, but far more predictable. Fewer clever shortcuts, fewer surprises.
That’s essentially how GTWY approaches agent workflows, and it’s been a practical way to keep agents aligned without relying on heavier prompts or post-hoc validation.
I think you did an amazing job of converting this into something that people can easily understand and use within their codebase - so props on that. It however would be the the right thing to give the proper credit to the source of idea - at least to thank them for their work and effort given this more of less is a direct copy of what they published https://www.intent-systems.com/ (not me and it’s something I use as well, but proper thing to do is give credit where credit is due)
hey, thank you, yup I fully agree with you. before publishing, I made sure to add a Credits section at the end of the blogpost. I will add it to GitHub too ;)
This follows, more or less, the principle of progressive disclosure, similar to skills. I think of it as precomputing constraints, not just context. The agent always reads the subfolder’s AGENTS.md, which re-asserts scope and authority. I plan to add another skill to periodically re-assert intent, preventing intent drift and keeping the intent layer up to date. You can already rerun /intent-layer to refresh it.
n our experience, most agent failures weren’t model issues but intent drift. The agent starts with a narrow goal, then gradually “helpfully” expands scope because nothing re-asserts intent between steps.
What worked for us was making intent explicit per step and treating it as a constraint, not just context. Each step declares what it’s allowed to do, which tools it can touch, and what kind of output is valid. After the step finishes, that authority is torn down.
The system feels less flexible, but far more predictable. Fewer clever shortcuts, fewer surprises.
That’s essentially how GTWY approaches agent workflows, and it’s been a practical way to keep agents aligned without relying on heavier prompts or post-hoc validation.
I think you did an amazing job of converting this into something that people can easily understand and use within their codebase - so props on that. It however would be the the right thing to give the proper credit to the source of idea - at least to thank them for their work and effort given this more of less is a direct copy of what they published https://www.intent-systems.com/ (not me and it’s something I use as well, but proper thing to do is give credit where credit is due)
hey, thank you, yup I fully agree with you. before publishing, I made sure to add a Credits section at the end of the blogpost. I will add it to GitHub too ;)
Truly curious here.
How is this different to asking the agent to add documentation?
This follows, more or less, the principle of progressive disclosure, similar to skills. I think of it as precomputing constraints, not just context. The agent always reads the subfolder’s AGENTS.md, which re-asserts scope and authority. I plan to add another skill to periodically re-assert intent, preventing intent drift and keeping the intent layer up to date. You can already rerun /intent-layer to refresh it.