Every prompt my team writes to our coding agent is stored in the ticket that asked for it. The ticket thread is the only way a developer can talk to the agent, so there is nowhere else for a prompt to go.
I'm Panth, and I lead the software team at Oizom, where Envizom is the platform that turns data from air-quality and environmental monitors into something cities and industries can act on. This post is about one design goal of our agent pipeline: the prompt is kept with the work, and it can be reviewed.
The only channel is the thread
A developer writes what they want in a ticket, in plain English, and drags it to Approved. There is no IDE open, no terminal and no prompt window. That ticket text is the whole spec.
Our orchestrator, orch, gives the ticket its own stack: a branch in every repo, its own backend, drivers, simulator and frontend, a copy of the dev database and a private preview URL. A coding agent does the work inside that stack. When it is done, it posts the preview link into the thread and moves the ticket to QAQC.
The developer opens the preview, tests it, replies in the same thread and moves the ticket back. The same agent, with the same context, picks up where it left off. Every follow-up is a message in the thread, so every follow-up is stored too.
When we set out to build this, it was one of five things we wanted from the start:
Every prompt should be stored with the work it produced, so we can review and coach how people ask for things.
What one thread holds
By the time a ticket is done, its thread holds the whole exchange, turn by turn:
| In the thread | Who writes it |
|---|---|
| What was asked | the developer, in the ticket and in each reply |
| What was built | the agent, with the preview link |
| Which preview was tested | the developer, by replying to that preview |
| The feedback | the developer, in the same thread |
| What the turn cost | posted on every agent turn |
| The PR and commit links | orch, after the ticket is dragged to Git Push |
Here is the shape of a real one. In the walkthrough video I asked for a camera layout change on a device page:
ticket camera layout change on the device page -> Approved
agent builds it in the ticket's stack, posts the preview -> QAQC
me "also handle more than 4 cameras with a horizontal scroll,
and set up 8 test cameras on this device" -> back to the agent
agent does both, the 8 test cameras in the ticket's own
database copy, posts the preview -> QAQC
me drags it to Git Push
orch commits, opens and merges the PRs, posts the links,
waits for CI, deploys to dev, checks health -> Completed
Every line of that is in the thread. Anyone can open the ticket and read what was asked, in the words it was asked in, next to what came out of it.
Reading prompts like pull requests
Because the prompts are stored, they can be reviewed. I read how each person on the team asks for things and coach them on it. That has been more useful than any prompting guide.
A prompting guide tells you what good asks look like in general. A ticket thread shows you how one person on your team asked for one change, what the agent built from it, and how many replies it took to get to something they were happy with. You can point at a specific message and talk about it, the way you would point at a line in a pull request.
The cost line matters here as well. Each agent turn posts its cost into the thread, right where the ask was made. The person asking sees what the ask cost, and it changes how they write the next one. That is on purpose too.
Why it needs one stack per ticket
A stored prompt is only useful if it sits next to the work it produced, and nothing else. That is where per-ticket isolation comes in.
Each ticket has its own branch in every repo, its own services and its own copy of the dev database. So a ticket's thread is a self-contained record: what was asked, what was built in that stack, what was tested on that preview. A ticket can sit in QA for a week while three others ship, and its history is still in one place, not mixed into anyone else's.
The thread is also where the rest of the process shows up. After Git Push, no agent is involved: orch commits, merges, opens and merges the pull requests, waits for CI, deploys to the dev VM and checks its health, and posts the PR and commit links back into the same thread. The prompt, the result and the review trail end up in one ticket.
What we get from it
- Every prompt the team writes is stored with the ticket it belongs to.
- I can review how people ask for things using their own tickets, not examples from a guide.
- The cost of each ask is visible where it was asked.
- The ticket is the audit trail: what was asked, what was built, what was tested and what feedback was given.
If your team uses coding agents, where do the prompts go once the work ships?
I lead the software team at Oizom. The full pipeline, including where we drew the line (dev only, human QA, visible cost), is in The ticket is the interface.
Top comments (0)