Two Sticky Notes on a Mailbox Called agent-queue and done

Our agent had no email address, and creating one took about five minutes. The four hours after that went into making the address useful.

That sounds backward until you think about hiring. The first day is often a parade of small access problems. A new person needs a key, a desk, a company email address and permission to see the things they are meant to work on. A helpful computer program hits the same wall. It can’t take part in your work if every door only recognizes you.

Two weeks of closed doors

For two weeks we had been running into that wall. We wanted the agent to handle real pieces of work, not just answer a question in a chat window. But it had no email address of its own. It could not be invited to a calendar event. It could not be given access to a document in its own name. It had nowhere to receive an assignment.

Borrowing a personal account

The first thing we tried was letting it borrow a personal account. That did not hold up. Sometimes a session could use the account and sometimes it could not. The sign-in permission was stored in a temporary place and disappeared when the session ended. The next time, it had to be set up again from scratch.

That cost patience more than anything else. Each small task began with the same question: would the agent still be allowed in? It also meant that if the agent shared a document, created a calendar event or sent a message, it looked as though a person had done it. If an assistant makes a mistake, people should be able to see who took the action.

A new inbox with a stored key

So we made a new inbox for the agent and connected a stored key to it. The technical name for the permission setup is OAuth. It is a way of giving a program a limited key so it can use an account without being handed your password. Once that key was connected to the new address and stored somewhere permanent, the setup stopped vanishing at the end of a session.

The new address gave the agent a name in the places where work already happens. A document could be shared with it. A calendar invite could be sent to it. An email could arrive for it. Its actions could now be traced back to that address instead of being mixed up with ours.

That changed how we thought about the inbox. Before, email was mainly a place where people sent information to other people. Now we could see it as a simple delivery lane for work.

Imagine a mailbox with two sticky notes on it. One says agent-queue. The other says done. A message with the first label is a job waiting to be picked up. The agent checks that label, reads the message, does the clearly described task and changes the label when it is finished. If a reply is needed, it can send one from its own address.

That is not a fancy new system. It is a mailbox doing a little more than it usually does. We did not complete the whole process that day. We got far enough to prove the checking part worked, then stopped. The point was to make sure the agent could stand on its own feet before we asked it to carry more.

What is still mixed together

There is a loose end. One inbox currently has three jobs. It receives the agent-queue work, sends out document links and collects automatic notices from scheduled tasks. That works at the current volume, but it is already a mixed drawer. A cleaner version would use separate addresses for work coming in, things being sent out and automatic alerts. We have not made that split yet.

We did not need a smarter agent. It could already reason well enough for the work we had in mind. What it lacked was membership, like a new employee who has never been given a badge or a mailbox.

Only the first of those three jobs was proven on the first day, and we stopped there on purpose. What the four hours bought was not automation. It was a stored OAuth key tied to one inbox, so that a shared document, a calendar invite or a reply would show up under the agent’s own name instead of ours. Until the inbox is split into separate addresses for work in, things out and alerts, that single address is both the agent’s badge and its whole desk, and the done label is still the only record of what it has finished.

If you plan to hand an AI agent real work, give it its own identity first: an email address with a stored sign-in key. Then what it does is visible as its own, and not mixed up with a person’s.

dxdev LESSON · paste into your AI coding agent
LESSON: An agent needs its own identity before it can be trusted with real work
SOURCE: dxdev.com/everyday-ai/email-address-that-made-the-difference
WHAT HAPPENED: An AI agent had no email address of its own, so it borrowed the operator's personal account to receive assignments, but the sign-in permission was stored in a temporary place and disappeared at the end of every session, requiring re-setup each time, and every action the agent took looked as though the operator had done it. Creating a dedicated email address and connecting a persistently-stored OAuth credential gave the agent a durable identity: it could be invited to calendar events, given documents in its own name, and its actions could finally be traced back to it rather than mixed up with the operator's own.
THE RULE: An autonomous agent doing real work needs its own durable identity, its own account, its own persistently-stored credential, not a borrowed one, both so its access survives between sessions and so its actions can be traced back to it rather than blended with the human's.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any agent or automation whose access to a third-party service, email, calendar, or documents, is borrowed from a human account rather than granted its own dedicated identity.
  2. Any credential or OAuth token stored only in a session-scoped or temporary location rather than a persistent, deliberately-configured store, causing re-setup on every session.
  3. Any inbox, queue, or shared resource handling more than one distinct job, incoming work, outgoing notifications, automated alerts, without separate addresses or labels for each.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.