From Prompt to Ticket

There is a quiet tax that anyone productive with AI is paying, and almost nobody names it.

You do not use one AI tool. You use five or six. One is good at drafting. One is good at structure. One reads your email. One sits in a different person's hands entirely. Or they are not even different tools, just the same assistant run in several places at once, a session for this project and a session for that one, each in its own workspace, none aware of the others. Each does its part of the day well. And then the work has to move: out of the tool that just finished it, into the next tool, or to the next person, or to that person's AI. There is no road for that. So you become the road. You copy the output out of one chat, you paste it into the next, you re-explain the background that the first tool already knew, and you do it again an hour later.

Nate B Jones, in a piece he calls Open Engine, gives this a name worth keeping: you have become the hallway between your agents. The AI is prompting you as much as you are prompting it.

I want to take his idea seriously, because it is good, and then do the thing he cannot do for you: decide how much of it actually fits a working professional who already has a system, and how much to leave on the shelf.

Open Engine as Nate B Jones presents it: each part has a job, and the work lives on a shared queue rather than in a chat. Source: Nate B Jones, "Open Engine" (youtu.be/QSK4vf_ZTRA).

The distinction that matters

Open Engine turns on one sharp line. A prompt asks for an answer. A ticket asks for a result to get done.

A prompt's output lives in a chat. It dies there unless a person carries it somewhere. A ticket is self-contained. The way I write one, it states the outcome, who owns it, the background that matters, what may be done, where to stop, and what has to be shown when it is finished. Because it carries its own context, the next worker can pick it up without reading the whole conversation. The next worker can even be a different AI that has never met the first one. The ticket becomes the place they talk.

There is a second distinction underneath it. Output is what an AI returns right now. Work is something a person can review, accept, and build on. A brilliant draft trapped in a private chat that nobody can find is not work yet. It is just output in a locked room.

Put plainly, the shift is from prompt mode, "write me a follow-up email," to work mode: "here is the call transcript, here is the decision we made, here are the constraints; draft the follow-up, flag what needs my judgment, and leave notes I can review." The first is a request. The second is a job, and a job can change hands without you standing in the middle.

Why this needs a foundation first

Routing work between agents only helps if the context survives the trip. That is why the order matters. Memory comes before routing.

Nate's own earlier project, Open Brain, was about exactly that: a memory you own, that any AI can read, so your context is not trapped inside one company's chat history. Routing is the next layer up. You cannot hand a job to the next agent if the job forgets itself on the way.

This is where the reader I write for has an advantage and a constraint at the same time. I am not describing an enterprise-wide AI platform, bought, deployed, and managed across a company. I am describing something smaller and more real: an individual, a team, or a department running disciplined knowledge work on top of a work OS they built themselves. Files they own. Context that persists between sessions. Rules the AI follows. That foundation, the subject of my guide Context by Design, is my Open Brain, already in place. Nate evolved Open Brain into Open Engine; this is the same move on top of Context by Design. The question is the next one: now that the context survives, how does the work move?

The fit test

Here is the part that AI content almost never does. It hands you a pattern and tells you to adopt it. Real adoption is rarely yes or no. It is a fit test against how you actually work, and the answer is usually partial.

Run Open Engine through it.

What fits today: the discipline. Writing in work mode instead of prompt mode costs nothing and needs no new software. A job with an outcome, the right context attached, a clear place to stop, and a record at the end of what was done and what was not. For most professionals this is not even new. It is the same instinct behind a good brief to a capable assistant. It just has to become the default way you talk to the machine, not the exception.

Even producing this piece, I had two AI sessions open at once: one handling the writing, one handling the website it would publish to. I caught myself doing the exact thing I am describing, carrying context from one to the other by hand, re-explaining to the second what the first already knew. The fix was not a board or a queue. I am present in both, so a queue would be machinery I do not need. The fix was smaller: I stopped relaying and wrote the second session a job, the outcome, the constraints, what finished looks like. That is the whole discipline, available today, at the cost of writing the job down instead of talking it through.

What fits later: the shared queue. Nate's full system puts the work on a board where agents claim a task, mark it in progress, leave a receipt of what they did, and stop to ask when they are unsure. That machinery earns its place the moment work starts running unattended, when an agent is doing something while you are asleep or in a meeting, and another has to pick up where it left off. If your work is still mostly you and one AI, in sequence, a board with locks and status columns is overhead you do not need yet. Adopt it when your own workflow pulls it in, not before.

The shared queue as system of record: an agent claims a task, does the work, and leaves a receipt, with no human copy-paste in between. Source: Nate B Jones, "Open Engine" (youtu.be/QSK4vf_ZTRA).

What does not fit, and why that is the interesting part. Nate runs his queue on a third-party tool in the cloud. For me, and for anyone whose work carries real confidentiality, that is where the pattern stops. Two rules I will not break: durable state lives in files I own, and confidential work does not leave for someone else's server to make my life slightly easier. That is not a weakness in his idea. It is a feature of my situation that his does not have to account for. The translation is straightforward, the same pattern, kept in the files I already own, with no outside silo. The shape of the idea survives. The tool it shipped on does not.

The real lesson

The pattern is worth having. The bigger thing is the habit of testing it.

Most patterns you will read about were born in software development. The people writing them code for a living, and their tools and examples assume it. The shape of the idea often transfers. The tooling often does not. The skill is not collecting patterns. It is knowing which part of one applies to you now, which part applies later, and which part you should refuse on principle.

So take the part that fits. Stop writing prompts and start writing jobs, with the context attached and the result defined. Let your own work tell you when you need more than that. And when a pattern arrives wrapped in someone else's tool, keep the idea and leave the tool.

The unit of useful AI work is moving from the prompt to the ticket. Your job is moving with it, from being the glue between your tools to being the one whose judgment they are waiting on. That is the version of the work worth keeping.