Skip to content
Kiberon LabsAgentic Engineering Ebook

Ticket Enrichment

Description

Section titled “Description”

Ticket enrichment is the intake mechanism that converts a high-level human outline into executable, context-rich work. It is the first stage of the delivery pipeline and a control point for scoping: it layers external research, internal company context, local code enrichment, and direct code pointers, then decides whether a task is ready for execution or must be decomposed first.

Enrichment is where the Coordination Model’s “reads parallelise” principle pays off most directly gathering context is read-only and embarrassingly parallel, so enrichment can fan out concurrent sub-agents across independent sources without the conflict risk that parallel writing carries.

Enrichment Layers

Section titled “Enrichment Layers”

Enrichment assembles context across several scopes (mapping to Context Layers):

  • External research prior art, library documentation, relevant standards. Treated as untrusted input: fetched web content is a prompt-injection surface (see Security), so it informs but does not command.
  • Internal company context organisation standards, domain vocabulary, related decisions, accepted technical debt.
  • Local code enrichment structural facts about the affected repository, drawn from Context Engines and agentic search rather than re-derived by reading files.
  • Direct code pointers the specific files, symbols, and call paths the work will touch, so the plan can declare its blast radius.

Decomposition: The Workability Decision

Section titled “Decomposition: The Workability Decision”

Enrichment is also a work-shaping system. Its key decision is workable or not:

  • A task is workable when its scope fits a short, well-scoped session with clear acceptance criteria the unit that produces the best autonomous outcomes.
  • A task that is too large or too ambiguous is decomposed into subissues, each re-entering the enrichment cycle, until the leaves are workable.

This makes decomposition a recursive control point. The criterion is not story points but executable scope: can a single planning-and-implementation cycle complete it with a verifiable result? Oversized tasks are the leading cause of long-horizon quality decay (see Runtime Context Management), so splitting early is cheaper than failing late.

Output Envelope

Section titled “Output Envelope”

Enrichment produces a standard artifact for the downstream Planning and Execution stage: the problem statement and business intent, acceptance criteria, architectural constraints, code pointers, complexity classification, and the original source material preserved for audit. The complexity signal is the primary input to Smart Routing and to the Controls autonomy decision.

Acceptance criteria belong here; concrete implementation detail does not that is the plan’s job. Keeping the issue at the level of intent and outcome preserves it as durable shared memory (see Collaborative Development Structure).

Multimodal and Conversational Intake

Section titled “Multimodal and Conversational Intake”

Enrichment is a back-and-forth process that needs escape hatches for humans to review and inject context. The most natural form is conversation across multiple threads including multimodal capture such as voice notes and annotated screenshots that are then aggregated into the intent artifact. Capturing intent in its original form and letting agents structure it is often cheaper and clearer than forcing a human to write perfect text up front (see Economics and Routing). The original artifacts are preserved for later audit.

There is currently no off-the-shelf solution for this conversational, multi-thread, multimodal intake aggregation; it is an identified build target.

Section titled “Related Concepts”