Rules & Behavior
How to define rules, corrections, and behavioral constraints for agents.
Last reviewed
The rule system
Pulse AI works best when expectations are explicit. Rules tell agents how to behave in a workspace: what to read first, what proof is required, what counts as overreach, and what must never be skipped.
Rules are not substitutes for the user's request. They provide durable operating constraints around that request: how to handle privacy, approval, evidence, lifecycle state, product language, and recovery.
What rules should cover
Useful rules are concrete. They should cover:
- Required context before starting.
- Role selection.
- Validation standards.
- Review and approval boundaries.
- Security and privacy limits.
- Git and delivery expectations.
- Product-specific language or behavior that must stay consistent.
Write a rule so another agent can act on it without guessing. Name the trigger, required behavior, boundary, and evidence. “Be careful” is weak; “redact account identifiers before a public screenshot and inspect the final frame” is operational.
Where behavior guidance lives
Pulse AI combines several layers:
- Workspace instructions define broad, always-on expectations.
- Role files define ownership and specialist responsibilities.
- Skills define repeatable procedures for a kind of work.
- Rubrics define how the output is judged.
- Corrections preserve explicit user feedback.
- Computed checks detect failures that can be proven from files or structured state.
Use the narrowest durable layer that fits. A writing preference may belong in a content rubric. A cross-agent safety boundary belongs in workspace guidance. A repeatable release sequence belongs in a skill and may also need a computed gate.
Corrections
When you tell an agent "don't do X" or "always do Y", Pulse AI can preserve that correction so future work does not repeat the same mistake.
Good corrections are operational, not emotional:
- "Use Pulse Narrate in public copy."
- "Do not treat generated launch content as approved unless the founder approves it."
- "Verify the live runtime before saying a UI issue is fixed."
A correction should record the date, context, and source so reviewers understand why it exists. Corrections remain active until they are intentionally replaced; urgency does not make them optional.
From correction to enforcement
Some feedback should be promoted beyond a written note. If the same mistake can be detected automatically, add a check. If every completed task must satisfy it, connect that check to the completion gate. If operators need to see the boundary before acting, also surface it in the product.
Promotion prevents a high-risk correction from depending on memory alone. It also gives reviewers concrete evidence instead of asking them to infer whether guidance was followed.
Enforcement model
Rules matter only when they affect behavior. Pulse AI pairs written guidance with review gates, validation checks, and board state so the system can catch misses before a human approves the work.
Agents should read applicable guidance before changing work, keep the task narrow, and cite current source or runtime proof. Reviewers should reject work that contradicts an active rule even when the output looks polished.
Recovery
If guidance conflicts, stop at the narrower and more recent authoritative source, preserve the conflicting evidence, and ask for a decision when the outcome would be hard to reverse. Do not silently pick the rule that makes completion easier.
If an agent repeats a corrected mistake, update the existing task with the finding, repair the output, and strengthen the durable enforcement layer. Do not create a duplicate rule with slightly different wording.