In Ivy Tendril, a GitHub issue becomes a pull request through a fixed sequence of stages: the issue arrives in the Inbox by webhook, an agent drafts a plan, a developer reviews and approves the plan, an agent executes it in an isolated git worktree, verification runs, the developer reviews the diff, and an agent opens the pull request. Humans act at exactly two points, the plan and the diff. Everything else is done by agents, and many tickets move through the sequence at the same time. This article follows one ticket through every stage.
The lifecycle at a glance
Ivy calls this workflow a software factory: a fixed sequence of stages in which agents do the work and humans inspect the output at defined points. The stages, who acts, and the condition that ends each one are listed below. The full reference is in the lifecycle documentation.
| Stage | Who acts | Exit condition |
|---|---|---|
| Inbox | Agent (webhook) | The issue is stored with its title, body, labels, and link |
| Draft plan | Agent (CreatePlan) | A draft with goal, scope, files, and verification steps exists |
| Plan review, checkpoint 1 | Human | The developer approves the plan, after any annotations and rewrites |
| Execute | Agent (ExecutePlan) | The agent reports the plan complete in its worktree |
| Verify | Agent | Tests and lint have run and the diff is ready for review |
| Diff review, checkpoint 2 | Human | The developer approves the diff |
| Pull request | Agent (CreatePr) | A pull request exists on GitHub for the plan's branch |
| Merge and cleanup | Human merges, agent cleans up | The worktree is removed and learnings are written to memory |
From issue to approved plan
The issue arrives
A user files issue #418 in the repository: "Export to CSV drops rows with commas in the description field." The GitHub integration delivers it to Tendril's Inbox by webhook. Nothing runs yet. The Inbox is a list of incoming items, and a developer decides which of them become plans. Bug reports from jam.dev arrive the same way.
CreatePlan drafts a plan
The developer selects the issue and chooses Create plan. The CreatePlan promptware reads the issue, its own memory of the repository, and the relevant code, and writes a draft. A typical draft names the goal, the files it expects to change (src/export/csv.ts and its test file), the approach (quote fields that contain the delimiter, following RFC 4180), and the verification steps (add a test with a comma in the description, run the existing export tests). The draft appears in Drafts.
Checkpoint 1: the developer reviews the plan
This is the first of the two human checkpoints. The developer reads the draft and finds one problem: the plan proposes to quote only the description field, but the same bug affects every free-text column. Rather than rewriting the plan by hand, the developer selects that paragraph and adds an annotation: "Apply the quoting to all string columns, not just description." The UpdatePlan promptware rewrites the plan with the annotation applied, and the revised draft is back for another look.
If the draft lacks detail, the developer can run ExpandPlan. If the annotations show that the ticket is really two pieces of work, for example a fix and a separate migration of the export module to a shared CSV library, SplitPlan divides it into two plans that proceed independently. When the developer is satisfied, they approve. The plan is now the specification for the run, and the agent is not asked to interpret the original issue again.
Execution and verification
ExecutePlan runs in an isolated worktree
On approval, Tendril creates a git worktree for the plan on its own branch and starts the chosen agent inside it. The developer picks the agent per plan: Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode, or another CLI agent. The workflow is the same whichever agent is chosen.
The worktree matters because other plans are running at the same time. Each has its own working directory and branch, so a half-finished change in one plan cannot affect another, and the main branch is untouched until review. The reasons for this design are covered in git worktrees for parallel AI agents.
While the agent works, the Jobs surface streams its output and tool calls: files read, commands run, tests executed, and the tokens and cost consumed so far. The developer can watch, or review another plan and come back. With a Cloudflare Quick Tunnel enabled, the same stream is available on a phone.
Verification runs
When the agent reports the plan complete, verification runs in the worktree: the test suite and the linter, with the resulting diff collected for review. The results are shown in the Review surface under three tabs: tests, lint, and diff. A failing test or a lint error is visible before any human spends time reading the change. Pro and Enterprise plans can also import verification results from CI. The case for treating verification as a gate rather than a suggestion is made in verification gates for AI-generated code.
Review, pull request, and cleanup
Checkpoint 2: the developer reviews the diff
This is the second human checkpoint. In Review, the developer reads the diff alongside the plan and the verification results. For issue #418, the diff touches src/export/csv.ts, adds a quoting helper, and extends the test file with three cases: a comma, a quote, and a newline inside a field. The tests pass and lint is clean. The developer approves the diff.
If the diff is not acceptable, the developer withholds approval, updates the plan with what was missing, and executes again. Nothing reaches GitHub without this approval.
CreatePr opens the pull request
The CreatePr promptware opens the pull request from the plan's branch. From here, the team's normal review and merge process on GitHub applies. Tendril's Pull Requests surface tracks the state of every open PR created this way.
After merge
When the PR merges, Tendril removes the worktree. The ExecutePlan promptware then writes what it learned to memory. For this ticket, an entry such as "The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export" is recorded, and the next plan that touches the export module reads it before starting.
The whole sequence, for a ticket of this size, takes minutes of agent time and two short reviews of human time. Ivy reports that its own team went from roughly 10 to more than 100 pull requests per day after adopting this workflow, with the two checkpoints unchanged.
How to start
Install Tendril, connect the GitHub integration so that issues arrive in the Inbox, and run one ticket through the sequence with a single agent before running plans in parallel.
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
On Windows, use irm https://cdn.ivy.app/install-tendril.ps1 | iex. The free edition, source-available under the Functional Source License, includes the full lifecycle. Pro and Enterprise add team features, verification imports from CI, and on-prem hosting.
Frequently asked questions
Can the agent skip a checkpoint if the change is small?
No. The two checkpoints apply to every plan. A one-line fix goes through plan approval and diff approval like any other plan. Small plans take less time to review.
What happens when two parallel plans change the same file?
Each plan works in its own worktree and branch, so the conflict does not appear during execution. It appears when the second pull request is rebased or merged, and is resolved in the usual git way. Splitting plans by module reduces how often this happens.
Does the issue have to come from GitHub?
No. Plans can start from a typed idea, a jam.dev bug report, the CLI, the REST API, or the MCP server. The GitHub webhook is one entry point to the Inbox.