I Was The Only Thing Connecting Claude, ChatGPT, and Codex. So I Built My Replacement.

Study Guide

Overview

In this video, Nate B. Jones (AI News & Strategy Daily) names a pain that anyone juggling multiple AI tools knows well: you are the only thing connecting Claude, ChatGPT, and Codex. You copy output from one tool, paste it into another, re-explain context, and carry the work between systems that do not talk to each other. His answer is a system he calls Open Engine, designed to make that invisible coordination work disappear so your agents start acting like a system you can operate instead of separate subscriptions.

The core promise: get your agents to stop behaving like separate products and start handing off work to each other (and to humans) without you being the messenger. It works for teams of humans and their agents, and for households, because the underlying shape of handoff pain is the same.

The Real Problem: You Are the Hallway

Nate frames the pain through a friend who has a baby, runs an agency, and uses Claude Code with loops and automations. She is fluent in AI. Her problem is not learning the tools, it is that she uses at least five different AI systems, each helping with one piece of the day, and she becomes the person who carries the work between them.

You cannot simply swap the tools out, because they are genuinely different. As Nate puts it: Claude is better at front-end design (it is intuitive), while OpenAI has a strong reputation for back-end engineering. So people who understand these tools end up "driving their own harnesses," coordinating themselves across tools to get their preferred model on each problem. That coordination is real, painful labor that AI-productive people simply absorb because the payoff is so high.

His memorable image: if every loop (research, writing, support, coding, scheduling) lives in its own room, the human becomes the hallway. The research loop finishes and the writing loop never learns what changed. The coding agent fixes a file, but the teammate who owns review only sees a vague summary unless you forward a pile of chats.

The Boundary Problem, Not a Model Problem

Nate is precise about what actually hurts. It is not a model problem and not an agent-capability problem. It is a boundary problem, the seam between agents:

  • Can the work leave Claude and go to Codex?
  • Can a teammate's agent pick up a task created by my agent?
  • Can a support loop escalate to the person with authority without losing the customer history or the reason the agent stopped?

He notes that tools like OpenClaw (action-oriented agents) and Hermes (agents that learn from repeated work) address real desires, but a very capable private agent can still become "another inbox or task queue you have to manage." Autonomy alone is not enough. The bottleneck Nate cares about is the handoff: who gets this next, and how do we pass it cleanly?

The Fix: Put the Work in a Shared Queue

The central move is deliberately simple. Put the work in a queue that both people and agents can read and write to. A queue can be Jira, a kanban board you coded, or a Linear ticket queue (Nate's preference). The specific tool does not matter; what matters is that it is a shared, readable, writable system of record.

A good ticket says: what needs to happen, who owns it, the background that matters, what the agent is allowed to do, where it should stop, and what it must show when done. That structure turns "asking an AI for help" into "giving it a job the next person or agent can understand."

Prompt vs. Ticket: A prompt asks for an answer. A ticket asks for a result to get done, and it can involve multiple agents that are not directly integrated. The ticket becomes the place they talk.

Why not a chat box or Slack? Because, as Nate argues bluntly, a chat box is a terrible way to manage state, and so is Slack. An agent needs to change files, create tasks, move statuses, and write drafts in a place where you can actually see what happened and audit it from any command line, not by querying chat transcripts.

The Five Components of Open Engine

Nate's specific build has five pieces that only work as a complete set; miss one and it does not hang together:

  • 1. A Linear queue. Chosen for its generous free plan and because it works well with the AI systems. You can substitute Jira or your own system.
  • 2. A setup skill. Tells your AI the protocol for using the ticketing system.
  • 3. A status skill. Lets the AI report and read state.
  • 4. A run-the-queue skill. Lets the AI work through assigned tickets.
  • 5. A smoke test. A clean test so you can verify the agent interaction actually works.

These skills are explicitly compatible with OpenClaw or Hermes. Nate is clear this is not anti-OpenClaw: "I love what OpenClaw has done... you can use those tools as much as you want," and you are not limited to only those tools.

How the Loop Actually Runs (Demo)

The basic Open Engine loop, as shown: a request becomes a clear Linear task assigned to the right operator. Then:

  • Codex wakes up, checks its assigned queue, and finds one eligible "agent instructions" issue.
  • Before working, it claim-locks the issue, moves it to agent working, and leaves an agent claim receipt.
  • The task carries the outcome, the sources, and the definition of done.
  • When finished, it moves the issue to the right status.

The receipt is not decoration. Nate's point: "I don't want to ask the agent, did you do the thing? I want to know it got done." No more copy-paste, no more manual coordination between LLMs.

Cross-provider delegation

His delegation example: Maya asks Codex to route a metrics task to Leo's agent, which happens to be Claude. Codex checks that Leo's agent is online, writes a self-contained Linear issue with all needed context, assigns it, and labels it "agent instructions." Leo's agent picks it up on its own heartbeat. That is two different people's agents, from different LLM providers, coordinating in Linear, with a visible handoff whose scope is not buried in chat.

The full loop and handling ambiguity

Request → issue → claim → work done → receipt → next item. If an agent hits ambiguity, it does not guess. It moves the issue to needs input and asks the exact blocking question. The human answers on that issue, the agent resumes, and the audit trail stays in one place.

Prompt Mode vs. Work Mode

Open Engine pushes you from "prompt mode" to "work mode." The model can be the same; the assignment is far clearer:

  • Prompt mode: "Write the follow-up email." Work mode: "Here's the client call transcript, the decision we made, the calendar constraints. Draft the follow-up, flag what needs my judgment, leave notes I can review later." (You can even pass that to a second agent that reviews only for brand language.)
  • Prompt mode: "Summarize this support ticket." Work mode: "Classify this ticket, attach the customer history, identify whether it's a known issue, create a product task only if it meets my escalation rule, and show exactly where you stopped and why."
  • Prompt mode: "Help me change my schedule." Work mode: "Pickup time for the kids changed, check what it affects, draft the two messages that might be needed to the school, and wait for approval before anything leaves the system."

Output vs. Work

A key distinction Nate draws: Output is what the AI returns right now. Work is what someone can review, accept, and build on. A beautiful brief written in a private chat that nobody knows about is just a draft in a room by itself. Open Engine is about getting from output to work without making humans the copy-paste path.

The Test for Open Engine

Nate offers a simple gut check for whether a system is doing this job:

  • Can the work get out of your chat?
  • Can it carry with it the sources it needs to do the work?
  • Can it respect limits (stop where it should)?
  • Can it come back and say: this is what I did, this is what I didn't do, here's the receipt?

If yes, even in a small way, the whole conversation shifts. You stop asking "what can one AI do in this session?" and start asking "what kind of work can my whole system carry without me being the messenger?"

Households and Teams: Same Shape

The pattern is identical for a school-pickup change and a sales pipeline: something changes, several things now depend on it, some parts can be handled by agents, some need a person. Open Engine does not replace the person, it just keeps the person from being the only one handing all of this off. Nate reports it has been a major load off for both his family (picking paint colors while moving houses) and his team (tagging each other's agents in, with a clear system of record instead of tracking agent messages in Slack).

Key Takeaways

  • You are the bottleneck. The pain isn't the models; it's that you manually carry work between Claude, ChatGPT, and Codex.
  • It's a boundary problem. The seam between agents (who gets this next, with what context) is where AI's promise gets bogged down.
  • Use a shared queue as the system of record. Linear, Jira, or a kanban board, anything both humans and agents can read and write. Chat and Slack are bad at managing state.
  • A good ticket beats a good prompt. Specify outcome, owner, context, allowed actions, stop conditions, and a definition of done.
  • Receipts and claim-locks make handoffs auditable. Know it got done; don't ask if it got done.
  • Agents shouldn't guess. On ambiguity, move to "needs input" and ask the exact blocking question on the issue.
  • Move from output to work without being the copy-paste path, across providers, for teams and households alike.
YouTube