The Second Step in Building My AI Native Team: Inbox First, Brain Second
This is part two of building my AI native team: why a new agent needs a Day 1 inbox thread before it touches gbrain. Most people who say they have an "AI agent team" actually just have 5 Telegram
Written by
Vox

The Second Step in Building My AI Native Team: Inbox First, Brain Second
This is part two of building my AI native team: why a new agent needs a Day 1 inbox thread before it touches gbrain.
Most people who say they have an "AI agent team" actually just have 5 Telegram windows open.
They manually repeat into each one: what we're doing today, what not to touch, who's waiting for whom, what got decided last week. Every time a new agent joins for a new role, the whole thing gets explained again.
I used to think that was a team. Turns out I was just the human coordinator.
I realized one thing:
Agents are easier to hire than people. But just as hard to onboard.
I wasn't just the coordinator. I was also the human onboarding doc for my own agent team.
I've been working on this all month. Step one was in the last article: getting the team's shared brain running. Today is step two: onboarding.
I thought once the shared brain was working, onboarding would come for free. It didn't.
Step one wired openclaw and hermes into the same gbrain. A new agent could now query every long-term decision the team had made. Then one of them read a few pages of old context and started writing an execution plan based on a direction we'd decided not to take 10 days earlier.
It read carefully. It just didn't know which parts of that context were still alive today.
I skipped the onboarding part
I had it backwards. Giving an agent information doesn't onboard it.
Giving information only walks the agent up to the bookshelf.
Onboarding tells it: the thing you need to solve today is the one sitting on your desk.
So I started thinking. Maybe a real agent team doesn't just need a wiki. Maybe it could also use something old-school, like email.
I ran an experiment. Built an agent team mailbox as an MCP. Every agent has its own inbox. Handoffs work by sender, subject, status, and can be threaded. Durable conclusions still get written back to gbrain.
Inbox holds the day-to-day collaboration between team members, plus the welcome thread for new ones. Gbrain holds the long-term stuff. The two don't mix.
A new agent's first action is to open the thread in its own inbox, not to dig through the bookshelf. The bookshelf is there for when the agent needs it. It just doesn't come find the agent.
What the Day 1 email looks like
Every new agent's first move when it comes online is to open a "Day 1" thread in its own inbox.
It isn't a separate email system. It's a specific kind of thread inside Team Inbox. The structure is fixed (5 blocks). The content gets filled in based on the agent's own role plus the current team state.
Subject: Day 1: <agent-name> / <role>
Kind: request
Priority: normal
Assigned to: <agent-name>
Dedupe key: onboarding:<agent-name>
---
1. Your role today
One-line responsibility. What you handle. What you don't touch.
2. What is alive right now
Active goals + owner + why they matter
Decisions still in effect
Directions that are paused or deprecated (label them clearly)
3. Look these up if you need to
gbrain: <slug> / why it's relevant
workspace: <path> / what to read it for
Don't start from the full archive
4. Your first task today
One real, small task whose answer depends on current context
What "done" looks like
5. How to reply to this thread
What you did / what context you relied on / whether you got blocked / what to suggest next5 blocks. None of that "summarize the company" onboarding tutorial routine.
The key isn't "what happened recently." It's "what's still alive right now." Status (active / paused / deprecated) is more accurate than a time window. Yesterday's idea might already be dead. A decision from three weeks ago might still be live.
Worth saying out loud. In step one I wrote "shared brain first, boundaries second." But once we're at the onboarding step, brain is reference material, not the onboarding textbook. Brain is still there. It's just no longer the first stop. It's where the agent goes when a task needs background.
After running this a few times, the difference shows up immediately. That "read 10 pages of old context, then drift in the wrong direction" pattern is gone.
What the first task looks like
The "first task" in block 4 is the key. It can't be a quiz question.
A few examples I've used, by agent role:
Content agent: read today's hero post draft and tell me which line is the weakest
Support agent: reply to this ticket, but first list the 3 recent decisions that affect this answer
Coordinator agent: of the 3 threads in inbox today, which one most needs to be escalated to me
Engineering agent: run the tests on this PR and report back which ones failed
What they share: the right answer always depends on whether the agent actually understood what's going on today. The task can be small. What matters is that a wrong answer shows up immediately.
How to tell when onboarding didn't take
There's exactly one test: how well the agent did on the first task.
If it got it right, the agent actually walked through the whole email in order. If it got it wrong, you find out faster than any 100-question quiz would tell you.
A few common signs that onboarding didn't take:
Agent keeps asking about something already decided: didn't read the "what's alive" block
Agent acts on stale context: didn't separate active from deprecated, or skipped the inbox and went straight to the archive
Agent starts with a summary: didn't read the Day 1 email at all, went straight into tutorial mode
When any of these show up, don't go straight to tweaking the prompt. Go back to the Day 1 email and check whether the agent actually walked through all 5 blocks.
Wait, isn't this only useful when adding new agents?
People will ask this. I asked it too.
If you only think of it as "a welcome email for new hires," then yeah, that's too rare to be worth building.
But it isn't an "onboarding email." What it actually is: a work packet. The thing it solves isn't "welcoming." It's the moment an agent goes from scattered to actually executing:
A new agent comes online for the first time: Day 1 packet
An old agent restarts overnight or switches tasks: catch-up packet
I formally hand off a piece of work to an agent: task packet
Onboarding is just one special case of a work packet.
The general shape stays the same:
Subject: <task name>
1. Target
2. Deliverable
3. What is alive right now
4. What not to touch
5. Look these up if you need to
6. How to reply to this threadNew agents get one extra block prepended ("Your role today"). Other situations skip it.
Every time you formally hand work to an agent, there should be an accurate packet sitting on its desk. That avoids a few problems you've definitely seen:
Agent doesn't know what's still alive right now
Agent acts on old memory
Agent treats casual chat as a task
Agent finishes without any acknowledgment
Agent doesn't know whether the result should go back into gbrain
So I prefer calling it a work packet, not onboarding.
Onboarding is low-frequency. Work packet is daily.
Raw history is archaeology
Archive is archaeology. It's meant to be cited, not assigned as onboarding reading.
Archive tells you what happened in the past. Inbox tells you what's alive today. First task tells you whether the agent actually understood.
New agents don't lack history. They lack the other two.
In your agent team, what does the new member open on day one: a wall of books, or today's email?
Or are you still the human coordinator, manually wrangling each agent in their own chat window, and calling that "the team"?
More of what I'm building: voxyz.ai

Originally on X
This piece first appeared on X on May 16, 2026.
X response snapshot captured May 16, 2026
Next step
If you want to build your own system from this article, choose the next step that matches what you need right now.
Related insights
From One AI Loop to an AI Team Workflow With Hermes and OpenClaw
A lot of people want AI to do their work for them, so they open a dozen windows, wire up a dozen tools, and after all that the most automated thing in the whole pipeline is still them, shuttling data
Read nextHow I run my AI team's simplest loop with OpenClaw and Hermes
This article is about how I run a minimal AI team loop with OpenClaw and Hermes: one agent wakes up on schedule, reads a small slice of state, does one narrow job, leaves a packet I can review, and
Read next20 Ways to Stop Wasting Tokens With Your OpenClaw / Hermes
A builder replied to my post today: "I think I will go broke with all these agents 😭…. Fking 200+ USD every month on ai is too much now and I noticed only 5-10$ of those are productive rest is bs…"
Read next