Published by Anvil Coder · Halvic Labs GmbH
Updated
Architecture rules for AI agents: prompts and checks
Put architecture rules in an AI agent's working context and support them with checks. Learn how to express constraints, examples and verification limits.
Why are wiki rules alone insufficient?
An architecture rule can guide an AI agent only when it is available in the relevant working context. A wiki can remain the central reference. Implementation still requires the applicable rules to enter the task context and to be maintained when the architecture changes.
Anvil Coder uses guardrails and project context for this. An instruction guides generation; appearing in a prompt does not guarantee compliance.
How do you make a rule concrete?
“Use clean architecture” leaves room for interpretation. A more testable instruction names its scope and a forbidden dependency. For example:
Domain classes must not import classes from the web adapter. New HTTP endpoints belong in the web adapter; business decisions remain in the domain.
This is an illustrative project rule, not a universal architecture requirement. Include permitted exceptions and a counterexample. Otherwise a rule may unnecessarily block legitimate changes.
What should be checked automatically?
An architecture test or static analysis can check an import restriction. A pattern check detects only the text patterns it defines. Deciding whether business logic belongs in a particular layer often still requires review.
Version the rule and its check together. Verify that the command is available in the actual environment and that it ran successfully. A test file in the repository is not evidence of execution.
How do you keep the rule current?
Update documentation, agent instructions and tests together when the architecture changes. Assign ownership and revisit existing exceptions. Commit history helps trace those changes; it does not automatically prove compliance.
The guardrail documentation explains configuration in Anvil Coder.
