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 next

5 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 thread

New 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