Jonathon's AI Wiki

Open Engine (Nate B Jones)

9 min read

Source: raw/I_Was_The_Only_Thing_Connecting_Claude_ChatGPT_and_Codex._So_I_Built_My_Replacement..md (YouTube, creator: Nate B Jones, “AI News & Strategy Daily”, https://www.youtube.com/watch?v=QSK4vf_ZTRA)

Open Engine is Nate B Jones’s described framework for getting multiple AI agents — Claude, ChatGPT, Codex, OpenClaw, Hermes — to coordinate and hand off work without a human acting as the manual relay between them. It is explicitly the third entry in his “Open ___” franchise: after Open Brain (portable memory) and Open Skills (portable procedures), Open Engine tackles the coordination/handoff layer. The thesis is that the bottleneck in AI-productive workflows has moved — from memory, to procedures, to the boundary between agents — and that “if every loop lives in its own room, the human becomes the hallway.” This article is a summary of the creator’s described framework, not a verified tool; the architecture below is what the video shows, not something independently tested.

Key Takeaways

  • The bottleneck is the boundary between agents. Jones frames it as a handoff problem, not a model or agent problem: can work leave Claude and land with Codex, can a teammate’s agent pick up a task your agent created, can a support loop escalate to a human “without losing any of the message or customer history and the reason for the agent stopping work.” AI is “moving a ton of generative energy into this tiny bottleneck around handoffs.”
  • Architecture = 5 components that only work together. A shared issue tracker (he uses Linear) plus four portable skills (setup, status, run-a-queue, smoke test). He stresses that “if you miss one of them, it doesn’t really go together.”
  • A ticket is not a prompt. “A prompt asks for an answer. A ticket asks for a result to get done — and it can have multiple agents even if the agents don’t know each other and aren’t directly integrated. The ticket becomes the place they talk.”
  • Coordination runs on a claim-lock + receipt protocol. An agent reads its queue, claim-locks one eligible issue, moves it to “agent working,” leaves an “agent claimed” receipt as proof-of-work, asks the exact blocking question (via “needs input”) instead of guessing on ambiguity, and finishes at “agent done.” The receipt exists so the human “doesn’t have to ask the agent, did you do the thing” — the proof is in the queue.
  • Cross-provider handoff with no direct integration. The core demo shows a Codex agent writing a self-contained Linear issue and assigning it to a teammate’s Claude agent, which picks it up on its own heartbeat — two different-vendor agents coordinating through the ticket alone.
  • CRITICAL CAVEAT — “Open” does not mean open-source. Despite the branding, Open Engine ships no public repo or skill files in the video. The full guide and the four skill files are gated behind Jones’s Substack community + an active Slack. The transcript describes the architecture; it does not release it. Treat all claims here as the creator’s framing of his own gated tool.

The Open ___ franchise

Open Engine is positioned as the third layer in a stack the same creator has been building (see Open Brain and Open Skills):

  • Open Brain — memory. “Every AI you use starts from zero unless you give it a true memory system that you control and that lives between your agents.” Context should not be trapped in one company’s chat history.
  • Open Skills — procedures. Portable, reusable agent procedures (skill.md-style) so you don’t re-explain how you work on every tool switch.
  • Open Engine — coordination. “Once the AI can remember, how does your work actually move?” This is the layer that moves work between agents and people.

The through-line: agents are “loop managers” (a useful agent is a remembered workflow that runs again, notices what changed, stops in the right place, and pulls the human in only when judgment is needed) — but isolated loops force the human to be the hallway. The research loop finishes and the writing loop doesn’t know; the coding agent fixes a file but the reviewer “only sees a vague summary unless you send them a bunch of chats.” Open Engine is the proposed fix for that handoff gap.

Architecture

Five components that “all add up together into a complete ecosystem”:

  1. A shared issue tracker / queue. Jones uses Linear (“generous free plan; works well with all the AI systems”). Explicitly substitutable: “You can use Jira. You can use your own system” — a self-coded Kanban or ticket queue works “as long as it is a Q that an agent can write to and you can read to.”
  2. Setup skill — tells the AI the protocol for using the ticketing system.
  3. Status skill — reading/moving issue status.
  4. Run-a-queue skill — drives a queue through the AI (read → claim → work → done).
  5. Smoke-test skill — a clean test that the loop works (see below).

The four skills are what “tell your AI how to use this tool” — and Jones notes “you can absolutely point your OpenClaw or your Hermes at this as a skill and use that too” (explicitly not anti-OpenClaw / anti-Hermes).

Coordination protocol

The named mechanics of the loop, as shown in the demo:

  • Agent reads its assigned queue and finds one eligible issue labeled “agent instructions.”
  • Claim-lock. Before doing the work, the agent claim-locks the issue, moves it to agent working, and leaves an “agent claimed” receipt (proof-of-work). The receipt “is not decoration — it actually lets you know what was done.”
  • On ambiguity, it doesn’t guess. It moves the issue to needs input and asks the exact blocking question; the human answers on that same issue, the agent resumes, and “the audit trail stays in one place.”
  • On completion it sets agent done and moves to the next item.
  • Status states: agent to-do → agent working → needs input → agent done.

A self-contained issue carries the outcome, the sources, and the definition of done — so an agent (or person) with no prior context can pick it up.

Cross-provider handoff (the core demo)

“Maya asks Codex to route a metric spec to Leo’s agent. Leo’s agent happens to be Claude. Codex checks that Leo’s agent is online and then writes a self-contained Linear issue with the context needed to act.” It assigns the issue to Leo’s agent, keeps it in agent to-do, and labels it agent instructions. “Now Leo’s agent can pick it up on its own heartbeat and the handoff is visible and it’s scoped — it’s not buried in chat.” This is the load-bearing claim: two people’s agents, from two different LLM providers, coordinating through the ticket with no direct integration between them.

Ticket vs prompt

The reframe Jones leans on: a prompt asks for an answer; a ticket asks for a result and carries owner + background + allowed actions + stop point + required proof. Three worked prompt-vs-work examples from the video:

  • Follow-up email. Prompt: “Write me a follow-up email.” Work: “Here’s the client call transcript, the decision we made, the promise (I don’t want to overstate), the calendar constraints. You draft the follow-up, flag what needs my judgment, and leave notes I can review later.” (And you can pass that to another agent for a brand-language review.)
  • Support ticket. Prompt: “Summarize this support ticket.” Work: “Classify this ticket, attach the customer history, identify whether this was a known issue, create a product task only if it meets my escalation rule, and show exactly where you stopped work and why.”
  • Schedule change. Prompt: “Help me change my schedule.” Work: “The pickup time for the kids has 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.”

The model can be identical across both modes — what changes is the clarity of the assignment and the ability to hand off to multiple agents or to a human.

Smoke-test recipe: create an issue titled “say hello” from the queue, assign it to a human or an agent, apply the instruction label, and confirm it can move to done. A deliberately clean check that the agent-interaction loop works end to end.

Try It

  • Stand up a queue both people and agents can read. Start with Linear’s free plan (or Jira, or a self-coded Kanban). The only hard requirement: an agent can write to it and you can read it.
  • Write one ticket as a statement of work, not a prompt. Include owner, background, allowed actions, stop point, and the proof required at done. Pick the task you most often relay by hand between two AI tools.
  • Define the status lane and the receipt. Agent to-do → agent working → needs input → agent done, with a “claimed” receipt as proof-of-work, so you stop asking “did you do it?”
  • Run the smoke test. Create a “say hello” issue, assign it, apply the instruction label, confirm it moves to done — proves the loop before you trust it with real work.
  • Add a “needs input” escape hatch. Instruct the agent to move the issue to “needs input” and ask the exact blocking question on ambiguity, rather than guessing — keeps the audit trail in one place.

Open Questions

  • Not open-source. Despite the “Open” branding, no public repo, skill files, or license is released in the video — the full guide and the four skills are gated behind Jones’s Substack community + Slack.^[inferred] The architecture is described, not shipped publicly.
  • Unverified. Whether the claim-lock/receipt protocol works as reliably as demoed across real different-vendor agents (Codex ↔ Claude) is the creator’s assertion from his own use; no third-party reproduction is cited.^[inferred]
  • No code shown. The exact mechanism by which an agent “checks that another agent is online” and runs on “its own heartbeat” (polling cadence, presence signal, MCP vs API) is not specified in the transcript.^[inferred]
  • Skill format compatibility. Whether Open Engine’s four skills follow Anthropic’s official Agent Skills SKILL.md convention or a parallel format is not stated.^[inferred]

Graph View

Backlinks