Hatch'd

Hatch’d connects to where your team does most of its work, takes one job off your plate, then keeps finding the next- requesting access only to the tools it needs along the way.

Comment

Hatch'd

An AI operator that learns the job from the work itself, does the work, and never guesses at the part it can't verify.

We didn't ask the operator what he does. We read 65,491 of his messages.

The inspiration

Tobias is an award winning art director and agency owner of a creative studio — nine clients, editors across LA, the UK, Ukraine, Korea and Vietnam. Every morning he does the same thing: read overnight chaos from five inbound sources, work out what actually matters, decide who should do each piece, write a brief good enough that the editor gets it first time, then chase, review, and ship.

He described that loop to us in a call. Then we pulled his entire workspace and discovered his description was roughly 15% of the real work.

That gap is the whole problem with AI agents for real work. The operator's loop isn't in their head in a form they can dictate. It's in how the work actually moves- in DMs, in dictated voice memos, in a video cut sent with the caption "good ?", in a correction that says "still feels kinda the same, some areas are better but not enough change."

So we stopped interviewing and started reading.

What we built

Hatch'd is an AI operator for Marketing Agencies. It connects to where the team already works, learns the operating loop from the real record, and then runs the loop and brings finished work back for approval.

The live build does the morning loop end to end:

  1. Ingest & normalise (S1) — five fragmented inbound sources (project-tool bots, chat DMs, chat channels, email, voice) collapsed into one deduped work queue. Voice is transcribed on ingest, unfiltered — because the briefs are dictated.
  2. Triage (S2) — type · client · medium · urgency · deadline, extracted with GPT-5.6 structured outputs.
  3. Route + brief (S3/S5) — pick the right person for this medium × client × skill, then generate a brief in that person's language and at their level.
  4. The Gate (S9) — the operator does not send. It presents. Approve with one tap, or reject with a required reason from a taxonomy derived from the operator's own correction history.
  5. Factual oracles (S4/S7) — run live and self-check: are the assets resolved and present? Is this the right version? Does the export match the client spec? Did the link go back to the channel it came from? Is the mandatory compliance text present for the regulated client?

The idea: split the job by verifiability

The reason agents fail at real operations is that they treat every step as equally automatable. It isn't. We split the operator's job in two and treat the halves completely differently:

FACTUAL — machine-checkable on day one. Asset present. Right version. Correct destination. Export spec match. Compliance text present. These have an objective oracle, so the operator can be right or wrong on its own, which is how it earns trust in week one without touching anyone's judgement.

TASTE — no machine tell, ever. Decoding a bad brief into the real ask. Adding the creative insight that wasn't in the brief. Picking the right person. Explaining it so they actually get it.

We have empirical proof this half can't be rule-written. Four voice memos in a row of the operator trying to articulate his own standard, ending with: "I don't know how else to really explain this, man."

So we don't try. Taste accrues through the gate. Every rejection forces a structured reason, and the reject log becomes the training set for a verifier that no competitor can reconstruct — because it's made of one specific operator's judgement, one decision at a time.

Autonomy compounds only where an oracle exists. Running an unverified loop where no oracle exists is how you get slop. That single constraint is the architecture.

The north-star metric

Not "did the output look right." Over ~10 mornings: does the reject rate fall, and does the gate move from approve-everything to exceptions-only? That transition is the loop earning unattended trust, and it's a measurable curve, not a vibe.

How we built it — Codex + GPT-5.6

Challenges

The loop wasn't where anyone said it was. The story was "briefs go into client channels." The data said the busiest client channel had 2,297 messages and the busiest editor DM had 19,554. The operator's real I/O surface is the per-person DM graph — so "route a brief" means writing into the right person's thread in that person's style, which changed the whole routing design.

The most important state changes aren't text. 461 deliverable videos have no audio track at all — they're cuts dropped into a DM with "what do you think?" A client approval arrived as a voice note. The revision tracker had to read approval signals out of images, silent video and speech, not chat text.

Proving coverage is harder than achieving it. Claiming "we processed everything" is worthless. Building the ledger that lets you point at any one of 11,154 files and say what happened to it and why is the part that makes the claim survive scrutiny.

Resisting the urge to automate the fun half. Generating briefs is the demo-friendly bit. Shipping it unattended would produce confident, wrong work at scale. Putting a forced-reason gate in front of it feels slower on day one and is the only reason it gets faster on day thirty.

What we learned

Interviewing an operator gets you the 15% they can narrate. The other 85% is only recoverable from the work itself — and it's disproportionately where the value is. Every one of the five findings that most changed the build came from the layers a normal pipeline throws away: voice memos, silent video, OCR'd screenshots, and meeting notes nobody ever reopened.

What's next

The corpus already mapped ten subsystems and the sequence to build them: the factual verifiers go airtight first (including the operator's single biggest recurring friction — a weekly manual reconciliation loop that is purely factual and therefore fully automatable), taste accrues through the gate in parallel, then multilingual onboarding of brand-new team members — the step that currently costs an hour of the founder's time per person per project.

Then the same operator gets pointed at a second revenue stream. The measure of success was never doing the existing work cheaper. It's hours back, leverage unlocked.

Built With

  • android-sdk-34;
  • buffers;
  • codex;
  • github-actions;
  • gpt-5.6-terra-medium;
  • gradle-7.6.4;
  • grpc;
  • kotlin-1.9.24;
  • openai
  • protocol
  • pytest-asyncio;
  • pytest;
  • python-3.11;
  • slack-sdk;
  • sqlite;
  • swift-5.9;
  • swiftui;
  • websockets;
  • xcodegen;
  • xctest;
Share this project:

Updates