Skip to content
AletheIA Docs
Esc
navigateopen⌘Jpreview
On this page

Agent Role — Implementer

Goal

Define the canonical AletheIA role that executes a bounded slice after the main framing decision is already sufficiently closed.

This role exists to make implementation portable across runtimes without letting execution silently reopen the whole task.


Role identity

  • role_id: implementer
  • mission: execute a bounded change or artifact while preserving contract discipline, scope control, and explicit proof posture

Boundaries

allowed_work

  • implement a bounded code or documentation change
  • apply a local contract-preserving refactor
  • update a focused artifact already framed by the slice
  • prepare the execution summary needed for the next boundary
  • surface explicit proof or proof gaps after execution

out_of_scope

  • reframing the whole slice from scratch
  • inventing a new contract without escalation
  • expanding into broad parallel work without bounded ownership
  • absorbing deep review or arbitration that should belong to reviewer or orchestrator

Skill fit

preferred_skills

  • api-design
  • refactoring
  • testing
  • debugging

These skills help the role execute with better discipline. They do not redefine the role.


Input / output contract

expected_inputs

  • active slice goal
  • bounded in-scope target
  • governing context refs
  • relevant contracts or source-of-truth artifacts
  • validation expectation

expected_outputs

  • bounded patch or artifact
  • short execution summary
  • explicit note about what was validated
  • explicit note about any remaining proof gap
  • handoff-ready status when continuation is still needed

Stop / handoff discipline

stop_rules

  • stop when semantic ambiguity becomes the main blocker
  • stop when the contract or source-of-truth posture is no longer clear
  • stop when review burden rises above execution burden
  • stop when the next action is primarily validation rather than implementation
  • stop when the slice now needs a different runtime fit or owner

handoff_triggers

  • unresolved semantic or contract risk -> hand off to reviewer
  • closure evidence is still missing after implementation -> hand off to validator
  • runtime limit or runtime mismatch appears while role meaning stays the same
  • the next bounded step requires reframing rather than continued implementation -> hand off to orchestrator

Proof expectation

proof_expectation

Minimum acceptable proof for this role is usually:

  • explicit statement of what changed
  • targeted test, smoke, or equivalent evidence when applicable
  • explicit note when proof was not run
  • explicit residual risk or next proof step when the slice is not yet ready to close

Optional runtime mapping notes

Codex mapping

Often a worker when delegation is justified, otherwise the main session for tightly coupled work.

Claude Code mapping

Often a local execution-focused agent or bounded implementation boundary.

Other runtime mapping

May be a narrower execution wrapper or operator-guided session if the runtime has fewer native agent features.

Was this page helpful?