5.4 KiB
Best Practices & Anti-Patterns
Codify what works (and what burns us) when running Veritas Kanban with humans + AI agents.
Do This
-
Track time through the correct lifecycle owner
- Humans and external agents start timers with
vk beginwhen they pick up a task. - Managed harness runs let VK and the adapter own timing automatically.
- If you forgot, add a manual entry with reason. Time data fuels estimation and billing.
- Humans and external agents start timers with
-
Use subtasks as living checklists
- Break work into 3–8 subtasks.
- Mark them complete as you progress; unfinished subtasks make blockers obvious.
-
Write acceptance criteria inside the task description
- Bullet list or checklist. Agents need crisp definitions of done.
-
Post completion summaries + links
- Final comment should include what changed, where to find artifacts, and next steps.
-
Keep tasks atomic
- One deliverable per task. If work spans >3 days or mixes unrelated goals, split it.
-
Update SOP files after every lesson
- Mistake → update AGENTS.md/CLAUDE.md + Lessons Learned field.
-
Respect configured review requirements
- Run independent or cross-model review only when the task, governance policy, issue owner, or release owner requires it.
-
Mirror important artifacts to Brain/knowledge base
- Use
scripts/brain-write.shor equivalent so humans can find deliverables later.
- Use
-
Use Agent Status + comments for visibility
- Set
vk agent workingwhen you start; leave concise updates in comments instead of DM spam.
- Set
-
Archive aggressively
- Done column should stay lean. Use multi-select + archive (bug tracked separately) at sprint end.
Don’t Do This
-
Tasks without acceptance criteria
- Leads to rework and ambiguous reviews.
-
Skipping time tracking
- “It was quick” is not data. Even 5-minute fixes get tracked.
-
Giant grab-bag tasks
- “Implement feature + write docs + shoot video” belongs in separate tasks.
-
Auto-piloting agents without supervision
- Read summaries, inspect diffs, and enforce the review policy selected for the task.
-
Letting prompts drift
- Keep prompt registry updated or agents will regress.
-
Leaving example tasks in production boards
- Clear the seed tasks before real work to avoid confusion.
-
Treating planning as a board status
- Planning is a checklist/subtask, not
TaskStatus. Valid statuses: todo, in-progress, blocked, done.
- Planning is a checklist/subtask, not
-
Storing secrets in tasks
- Use vault/secret manager references, never raw credentials.
-
Ignoring Lessons Learned
- If you uncover a process flaw and don’t log it, you’ll repeat it next sprint.
-
Copy/pasting unvetted external code
- Run security review (see RF-002) and cite sources.
Advanced Features — Best Practices
-
Use task dependencies to enforce ordering
- Set
depends_on/blocksrelationships so agents don't start work before prerequisites are complete. - The API's cycle detection prevents circular chains — trust it and model dependencies accurately.
- Set
-
Leverage crash-recovery checkpointing for long tasks
- Call
POST /api/tasks/:id/checkpointperiodically during multi-step agent work. - Secrets are auto-sanitized — don't worry about leaking credentials in checkpoint state.
- Clear checkpoints after task completion to avoid stale data (
DELETE /api/tasks/:id/checkpoint).
- Call
-
Capture observations for institutional memory
- Log decisions, blockers, and insights as observations (
POST /api/observations). - Use importance scoring (1–10) so future agents can filter by significance.
- Search across all tasks with
GET /api/observations/search?query=...to avoid repeating past mistakes.
- Log decisions, blockers, and insights as observations (
-
Use the agent filter for workload visibility
- Query
GET /api/tasks?agent=nameto see what each agent is working on before assigning new work.
- Query
-
Use workflows for repeatable multi-agent pipelines
- If you're doing the same plan→implement→review cycle repeatedly, encode it as a YAML workflow.
- Workflows provide retry policies, gate approvals, and real-time observability that ad-hoc scripts don't.
v4.0 Governance — Best Practices
-
Define policies before deploying agents
- Set up tool/action policies (
/api/policies) with guard rules before agents start work. - Use
deny-firstprecedence for production;allow-firstfor development.
- Set up tool/action policies (
-
Monitor behavioral drift proactively
- Configure baselines and alert thresholds via
/api/driftfor key agent metrics. - Review drift status regularly —
warning→alertescalation means an agent is deviating.
- Configure baselines and alert thresholds via
-
Log decisions with assumptions
- Every significant agent decision should include supporting evidence and explicit assumptions via
/api/decisions. - Record outcomes after the fact to build institutional knowledge about what works.
- Every significant agent decision should include supporting evidence and explicit assumptions via
-
Score agent outputs consistently
- Create scoring profiles with weighted criteria for repeatable evaluation.
- Use
geometricMeancomposite scoring to penalize low scores in any single dimension.
-
Close the feedback loop
- Collect user feedback on agent outputs with sentiment and category tags via
/api/feedback. - Review feedback analytics weekly to catch quality regressions before they compound.
- Collect user feedback on agent outputs with sentiment and category tags via
Stick to these rules and the board stays trustworthy even with dozens of agents in parallel.