Agent Pipelines

Agents run inside a structured execution pipeline. This page covers how that pipeline works: when agents fire, how they pass data between steps, and how you chain tools and agents together for complex workflows.

Pipeline overview¶

When a ticket enters execution, JuhJuh runs a pipeline with defined entry points for your agents. Each entry point fires at a specific moment in the lifecycle. You choose the timing when you attach an agent to a ticket.

graph TD
    A[Ticket enters execution] --> B{Standalone or Autonomous agent?}
    B -->|Yes| C[Agent handles entire ticket]
    B -->|No| D[Before All hooks]
    D --> E[Main execution starts]
    E --> F[Before Each hook]
    F --> G[Execute prompt round]
    G --> H[After Each hook]
    H --> I{More rounds?}
    I -->|Yes| F
    I -->|No| J[After All hooks]
    J --> K[Execution complete]

Two paths through the pipeline. If a standalone or autonomous agent is attached, it takes over the entire ticket. No main pipeline runs. Otherwise, hook agents fire at the configured timing around the main execution.

Hook timing¶

Hook agents fire at four points in the pipeline. Attach multiple hooks at each point. They run in priority order within their timing slot.

Each hook can carry a condition expression. The condition evaluates against the ticket's metadata before the hook fires. If the condition returns false, the hook is skipped for that execution. This lets you attach a single hook agent to many tickets while controlling exactly when it activates.

Priority ordering¶

When multiple hooks share the same timing slot, they execute in priority order (lowest number first). Set priority on the ticket-agent attachment. A priority-1 "before all" hook runs before a priority-5 "before all" hook.

Standalone and autonomous execution¶

Two agent modes bypass the main pipeline entirely.

Standalone. The agent handles the full ticket from start to finish. No prompt selection, no main execution loop. The agent's own instructions and tools drive the entire process. Use standalone for tickets that need a fundamentally different workflow than the default pipeline.

Autonomous. The agent runs a self-directed reasoning loop. It evaluates the ticket, chooses tools, executes them, inspects the results, and decides whether to continue or stop. Each iteration is a complete think-act-observe cycle.

The autonomous loop follows this structure:

1. Load ticket context, connected tools, matched skills, and relevant knowledge
2. Build a prompt with all available context
3. Call the AI model
4. Parse the response for tool invocations
5. Execute any tool calls (capped at 20 per session by default)
6. Record the step with token counts, cost, and duration
7. Check for a completion signal
8. If not done, loop back to step 2 with updated context
9. Finalize: save the summary, create artifacts, post comments

The maximum iteration count defaults to 10. You can adjust it per agent. If the agent hits the limit without completing, the session ends with a partial result.

Context injection¶

Context injection is what makes the pipeline composable. Turn it on for any hook agent, and its output feeds directly into the next step as additional context.

A "before all" hook that gathers API documentation, for example, produces output that becomes part of the main execution's context window. A "before each" hook that checks the current branch state passes that information into the next prompt round.

Multiple hooks chain together. Priority-1 hook output is available to priority-2. Priority-2 output feeds into priority-3. The main execution receives the accumulated context from all "before all" hooks.

graph LR
    A[Hook 1: Gather docs] -->|output| B[Hook 2: Check branch]
    B -->|accumulated context| C[Main execution]
    C -->|output| D[Hook 3: Run linter]
    D -->|output| E[Hook 4: Post summary]

Context injection is optional per hook. Hooks without injection still run, but their output stays in their own session log rather than flowing downstream.

Tool pipelines¶

Tool pipelines let you chain multiple tool calls into an ordered sequence. Each step's output feeds into the next step through input mappings.

Define a pipeline with named steps. Each step specifies a tool, its parameters, and an optional transform. Use $prev references to pull values from the previous step's output.

Input mappings¶

Reference previous output with $prev.field_name. If step 1 returns a list of PR IDs, step 2 can reference $prev.ids to process each one.

Transforms¶

Apply transforms between steps to reshape data:

Example flow¶

A three-step pipeline that finds open PRs, extracts their IDs, and posts a summary:

Step 1: list_pull_requests(status="open") ↓ output: [{id: 42, title: "..."}, {id: 43, title: "..."}] Step 2: extract_ids($prev) → transform: extract_ids ↓ output: [42, 43] Step 3: post_summary(pr_ids=$prev, channel="engineering")

Tool pipelines run within agent sessions. They respect the same tool call limits and timeout constraints as individual tool calls.

Skills in the pipeline¶

Skills inject learned capabilities into agent executions. When a ticket matches a skill's trigger patterns, the skill's instructions are added to the agent's prompt automatically.

Up to 5 skills can activate per execution, selected by relevance and usage history. High-performing skills surface more often. Skills that consistently produce poor results can be deactivated.

Skills compose with the rest of the pipeline. A "before all" hook might gather context, a skill might inject domain-specific instructions, and the main execution combines both.

Batch execution¶

Run a single agent across multiple tickets in one operation. Batch execution is useful for bulk actions like running a code quality scan across an entire sprint or applying a formatting standard to all open tickets in a project.

Configure a batch by selecting:

• The agent to run
• Filters: project, status, type, sprint, or assignee
• Whether to skip tickets that match certain conditions

The batch tracks progress across all tickets: total count, completed, failed, and skipped. Cost aggregates across the full run. A summary report generates when the batch completes.

Batches handle failures gracefully. If one ticket fails, the batch continues with the remaining tickets. The failed ticket is logged with its error, and you can retry it individually.

Parallel agents¶

Agents attached with parallel execution mode fire alongside the main pipeline without blocking it. Their results merge into the ticket's completion summary after the main execution finishes.

Use parallel agents for work that does not need to happen in sequence: running a security scan while the main pipeline generates code, or collecting metrics while a deployment agent works.

Parallel agents run in their own sessions with independent tool call and iteration limits.

Safety and limits¶

Every pipeline execution operates within defined boundaries.

Condition guards on hook agents prevent unnecessary execution. Sandbox policies restrict autonomous agents to their connected resource directories. Every tool invocation is logged for audit, recording the tool name, resource type, success status, and duration.

Monitoring pipeline runs¶

Pipeline execution is fully observable. Every step broadcasts status updates in real time to the ticket view.

Sessions record their trigger source: UI, API, Slack, schedule, webhook, or event. Trace any execution back to exactly what started it.

Designing effective pipelines¶

Start simple. A single "after all" hook that runs your linter covers most code quality needs. Add complexity only when you need it.

Validate first. A "before all" hook that checks prerequisites catches problems before they waste execution tokens. Verify the target branch exists, required resources are connected, and the ticket has enough detail.

Keep hooks focused. Each hook should do one thing well. A hook that validates, gathers context, and posts to Slack is doing three jobs. Split it into three hooks with the right priority order.

Use context injection deliberately. Not every hook needs to pass output downstream. Only enable injection when the next step genuinely needs the data. Extra context consumes tokens without adding value.

Test with dry runs. Attach agents to a low-priority ticket first. Review the session log to verify timing, context flow, and tool usage before rolling the pipeline out to your team.

Related¶

• Agents: create and configure the agents that run in your pipelines
• Tickets: the execution lifecycle that pipelines attach to
• Automation: auto-classification, auto-triage, and auto-play workflows
• Instructions: define the rules your agents follow at every level
• Prompt Templates: reusable prompts that complement agent pipeline steps
• Resources: connect the tools and services your pipeline agents need