Last week I argued that your first AI hire should be a Chief of Staff: one agent that protects your attention, learns your standards, and eventually helps manage the others.

Then I went looking at how people are actually building one.

Dan Shipper has created Tend, a system inside Codex that pulls email, Slack, meeting notes, and company updates into one place and helps him act on them.

It is an impressive picture of where this is going.

It might not be the right place to start.

Katie Parrott at Every saw an early version of Tend and had Codex build her own version, called Attention Desk. Then she abandoned it.

The problem was not the AI. Tend solved Dan’s real problem: a CEO’s information overload. Attention Desk solved a version of Katie’s workday that did not really exist. Instead of removing a queue, it created another one.

I copied part of Tend too.

I liked the email triage and the card it produced for each message worthy of my attention. I left out most of the Slack and company-update pieces because I like going into Slack and seeing what’s happening myself and our team is small. I don’t need company updates. The rest of Dan’s workflow would have taken up space and, more importantly, my attention.

That is the first rule of the AI Chief of Staff:

Do not start with the agent you admire. Start with the interruption you already resent.

Look for the recurring queue that pulls you out of your work three times a day or a week: your inbox, new leads, unpaid invoices, scheduling requests, proposals, or customer issues.

A good first queue has four traits:

Your first agent should not “run the business.”

It should read one queue and answer three questions:

What deserves my attention? Why? What should happen next?

You can build the first version inside the desktop AI tool you already use. I have both Claude and Codex, but I usually default to Codex because it feels faster and more direct to me.

The tool matters less than the order in which you build.

Give the agent one page explaining who matters, what counts as urgent, what to ignore, and what it must never do.

Then give it examples of good work.

Suppose proposals are the first queue you want to tackle. Upload three or four good proposals. Explain what you like about them. Describe how you review a proposal and what usually causes you to send one back.

Then review several live proposals together. Correct the agent when it misses something and explain why.

Treat it like a new assistant: give it examples, explain your corrections, and supervise its early work.

At this rung, it recommends. It does not send, delete, approve, or update anything.

Once the agent becomes useful, tell it to save the corrections that should still matter tomorrow.

This is what a memory file is good at. It becomes the agent’s handbook:

The memory file keeps you from explaining the same judgment repeatedly. It tells the agent how you work.

You can later add personality files, reusable skills, more tools, and more durable agent systems. But you do not need to install a complex open-source platform like Open Claw or Hermes simply because someone else built something impressive with it.

Steal the useful ideas first. Add the machinery when your work demands it.

Eventually, the agent may start handling more work. The rules still fit inside a memory file, but the work itself becomes too large and changes too often.

That is when you may need a database.

A memory file is the employee handbook. A database is the operating ledger.

The memory file tells the agent how to judge a proposal. The database tells it:

Could you put all of that in a file?

Yes—at first.

You can also track your inventory on a legal pad. The problem is not whether it is technically possible. The problem is whether you can still trust it when hundreds of items are changing.

In one large file, different records begin using different names and formats. Updates overwrite one another. Important dates go missing. Two agents can act on different versions of the same information. Answering a basic question requires rereading the document and hoping the right detail is still there.

A database gives every lead, invoice, proposal, or customer issue its own record. The agent can update one item without rewriting everything else. Multiple agents and scheduled routines can work from the same current information.

Now you can ask exact questions:

Which proposals have been waiting more than five days?

What kinds of recommendations do I usually reject?

Are unpaid invoices being resolved faster?

Where does the agent keep making the same mistake?

A database does not make the agent smarter. It makes the work traceable.

It also gives you something a memory file cannot reliably provide at scale: measurement. You can track what the agent found, what it recommended, what you accepted, what happened next, and whether performance is improving.

The memory file guides judgment. The database tracks state.

Or, more simply:

Use files for source material.
Use memory for judgment.
Use a database for tracking large volumes of work over time and work that keeps changing.

Modern AI tools can help set up and connect a service such as Supabase. You may never need to work directly inside the database. Codex can do almost everything for you.

Pick one queue. Write ten sorting rules. Run the process manually three times.

Do not schedule it until you can review its output in five minutes.

Do not let it act until its recommendations are boringly reliable.

Do not build a database until the workflow is producing repeated decisions and records worth tracking.

Your first Chief of Staff does not need to be sophisticated.

It needs to give you back one quiet hour—and learn why.