Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Your four artifacts line up almost exactly with where role boundaries become testable: product owner defines acceptance, architect defines scope, Dev/QA gets write authority, and the reviewer stays read-only. Would you be open to contributing one sanitized completed workflow as an interoperability fixture? No tool migration: map the existing skill outputs to role/task contracts, record a baseline PASS, add one deliberate contradiction (for example, /code-reviewer is asked to modify a file or Dev/QA touches an out-of-scope path), repair it, and publish setup time plus any false positives.
ARC only validates the supplied declarations offline; it would not prove that Claude enforced the roles. Repo and evaluation template: github.com/suirindo/agent-role-con...
This is an interesting direction. The distinction between defining role boundaries and actually enforcing them is important.
Our current approach focuses on making each role’s responsibilities, inputs and outputs explicit. I can see value in testing how those contracts hold up when deliberately challenged, particularly around write permissions and scope boundaries.
An interoperability fixture sounds like a useful way to explore this. I’ll take a closer look at ARC.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Interesting perspective. I particularly agree with the distinction between validating declared contracts and verifying actual runtime enforcement. That’s an important gap as we move from experimenting with agents to putting them into real organizational workflows.
At KumiQ, we’re looking at this from the broader organizational perspective: how to make AI capabilities reliable, governed and valuable in practice.
I don’t have capacity to explore an interoperability experiment right now, but I think we’re looking at complementary parts of an important problem. Definitely worth keeping the conversation going.
Founder & CEO of Netsujo. Building trustworthy AI agent systems, with a focus on task boundaries, verification, and production reliability. Creator of Agent Role Contracts (ARC).
Thanks, Lital. I appreciate the thoughtful response, and completely understand the bandwidth constraint.
I think the complementary perspective is valuable. ARC focuses on making declared roles, authority, and task boundaries checkable before execution. But organizational trust also requires runtime enforcement, accountability, and evidence that the intended outcomes actually occurred.
One question we're exploring is how these layers can connect without creating another governance burden for the people using AI agents.
I'll keep sharing concrete findings as our experiments progress. Looking forward to following what you're building at KumiQ as well.
I think that last point is particularly important. Governance only works if it becomes part of how people work with AI, rather than another layer of complexity they have to manage.
There’s an interesting opportunity to connect technical assurance with organizational adoption. Looking forward to following your experiments with ARC as well.
I agree with your point that scope creep gets a hard stop only when the boundaries are written down before implementation starts. In my own reviews, a generic "review this" prompt tends to praise the code and approve unrelated cleanups, because it has no standard for what counts as out of scope. A reviewer role with a fixed checklist changes that by forcing a separate answer for each item — whether each change maps to the spec, whether any new dependency appeared, and whether any unrelated file was touched — so an extra change cannot hide inside a generally good-looking diff. Non-English teams run into the same problem, and the curated Chinese collection at github.com/laolaoshiren/claude-cod... includes a Chinese-output code-review skill built around the same checklist idea. That explicit structure, rather than a smarter model, is what makes the "no" at review time feel repeatable instead of personal.
Exactly. A reviewer needs something concrete to evaluate against, otherwise it tends to become another model validating its own assumptions.
I particularly like your point about making every review item independently accountable. It makes the review much more reproducible and less dependent on the model’s interpretation of what good code looks like.
The multilingual angle is interesting too. The principles should remain consistent regardless of the language used by the team.
Tokenade is what I build, and I would check the reads before the roles. A role that loads only what its job needs costs less than one that reloads the whole repo.
Good point. Role separation shouldn’t mean every role reloads the entire context.
There’s an interesting balance between giving each role enough context to make sound decisions and keeping its working context focused on its actual responsibility.
This is also where separating organizational standards from task-specific context becomes important.
Your four artifacts line up almost exactly with where role boundaries become testable: product owner defines acceptance, architect defines scope, Dev/QA gets write authority, and the reviewer stays read-only. Would you be open to contributing one sanitized completed workflow as an interoperability fixture? No tool migration: map the existing skill outputs to role/task contracts, record a baseline PASS, add one deliberate contradiction (for example,
/code-revieweris asked to modify a file or Dev/QA touches an out-of-scope path), repair it, and publish setup time plus any false positives.ARC only validates the supplied declarations offline; it would not prove that Claude enforced the roles. Repo and evaluation template: github.com/suirindo/agent-role-con...
Would one of your shipped tasks be suitable?
This is an interesting direction. The distinction between defining role boundaries and actually enforcing them is important.
Our current approach focuses on making each role’s responsibilities, inputs and outputs explicit. I can see value in testing how those contracts hold up when deliberately challenged, particularly around write permissions and scope boundaries.
An interoperability fixture sounds like a useful way to explore this. I’ll take a closer look at ARC.
Thanks, Lital. I agree — the important test is whether role boundaries hold when challenged, not just whether they're clearly documented.
Your four skills provide a useful starting point. I'd suggest a small, fully synthetic interoperability fixture with three cases:
For each case, we could compare the declared contract, expected and observed ARC verdicts, and separate runtime evidence where available.
Importantly, an ARC declaration check wouldn't be treated as proof that Claude Code actually prevented a write.
We could also measure setup time and false positives, without requiring production code or changing your existing workflow.
Would a small synthetic example mapped to your four skills be a useful first step?
Interesting perspective. I particularly agree with the distinction between validating declared contracts and verifying actual runtime enforcement. That’s an important gap as we move from experimenting with agents to putting them into real organizational workflows.
At KumiQ, we’re looking at this from the broader organizational perspective: how to make AI capabilities reliable, governed and valuable in practice.
I don’t have capacity to explore an interoperability experiment right now, but I think we’re looking at complementary parts of an important problem. Definitely worth keeping the conversation going.
Thanks, Lital. I appreciate the thoughtful response, and completely understand the bandwidth constraint.
I think the complementary perspective is valuable. ARC focuses on making declared roles, authority, and task boundaries checkable before execution. But organizational trust also requires runtime enforcement, accountability, and evidence that the intended outcomes actually occurred.
One question we're exploring is how these layers can connect without creating another governance burden for the people using AI agents.
I'll keep sharing concrete findings as our experiments progress. Looking forward to following what you're building at KumiQ as well.
I think that last point is particularly important. Governance only works if it becomes part of how people work with AI, rather than another layer of complexity they have to manage.
There’s an interesting opportunity to connect technical assurance with organizational adoption. Looking forward to following your experiments with ARC as well.
I agree with your point that scope creep gets a hard stop only when the boundaries are written down before implementation starts. In my own reviews, a generic "review this" prompt tends to praise the code and approve unrelated cleanups, because it has no standard for what counts as out of scope. A reviewer role with a fixed checklist changes that by forcing a separate answer for each item — whether each change maps to the spec, whether any new dependency appeared, and whether any unrelated file was touched — so an extra change cannot hide inside a generally good-looking diff. Non-English teams run into the same problem, and the curated Chinese collection at github.com/laolaoshiren/claude-cod... includes a Chinese-output code-review skill built around the same checklist idea. That explicit structure, rather than a smarter model, is what makes the "no" at review time feel repeatable instead of personal.
Exactly. A reviewer needs something concrete to evaluate against, otherwise it tends to become another model validating its own assumptions.
I particularly like your point about making every review item independently accountable. It makes the review much more reproducible and less dependent on the model’s interpretation of what good code looks like.
The multilingual angle is interesting too. The principles should remain consistent regardless of the language used by the team.
Tokenade is what I build, and I would check the reads before the roles. A role that loads only what its job needs costs less than one that reloads the whole repo.
Good point. Role separation shouldn’t mean every role reloads the entire context.
There’s an interesting balance between giving each role enough context to make sound decisions and keeping its working context focused on its actual responsibility.
This is also where separating organizational standards from task-specific context becomes important.
Open to pushback on the sub-task size threshold in /architect. I set it at ~400 LOC but honestly guessed.