A useful amount of my work starts with an email. Something broke. A customer noticed a problem. A service sent an alert. Someone has an idea worth trying. The background is already there, usually underneath a few signatures and a reminder to consider the environment before printing.
I want to forward that message, add what I need done, and have the work move forward. Instead, I can end up copying it into a task, opening an AI chat, explaining the project, asking for an investigation, checking the proposed fix, and reminding the agent that fixing a file and fixing the problem are different things. At some point, the time-saving assistant has acquired a full-time supervisor. Me.
That is why I built Codex Inbox around the tools I already use: email for the request, Asana for keeping track of the work, and Codex for carrying it out. It is a working system I am using and refining, with rules for ownership, permissions, review, and what counts as finished. The interesting part is how those pieces fit a real working day.
Forward the problem without rewriting its history
The starting point is deliberately ordinary. I forward an email into Codex Inbox and add a short instruction identifying the project and the outcome I want. For a website alert, that could be: investigate the cause, fix it if a change is needed, release it within the project’s permissions, and check the live result.
The forwarded message provides background. My instruction defines the job. That distinction matters because an email can contain requests, automated warnings, quoted replies, and advice from people who have no authority to change the system. Receiving a message should not turn everything inside it into an instruction the agent follows.
The request becomes an Asana task, with the original context attached to it. The task holds the outcome, allowed actions, completion requirements, and any decision that needs me. I can see what is waiting, what is underway, and what actually needs my attention without reconstructing the story from several conversations.
Email works for me because I am already there. If your team does its work in Slack, a support desk, or a project board, that may be the better starting point. The useful choice is the place people will use when they are busy, not the place that looks best in a software demo.
Give each request an owner and a place to continue
The Inbox dispatcher checks for eligible work on a five-minute cycle and handles one repair at a time. Each request stays tied to one visible Codex work chat and its working files. Before starting another pass, the dispatcher checks whether that work already has an owner.
That avoids two agents trying to repair the same problem because both noticed an unfinished task. It also gives me somewhere to add a correction or follow-up without starting from scratch. Earlier findings, decisions, and limits stay with the job.
Asana makes the state visible. Incoming work waits in the queue. Active work moves into progress. Review Ready is reserved for a real human dependency, with a clear question and a named next owner. If the agent can safely keep working, it should keep working. Asking me to say “continue” every few minutes is a peculiar definition of automation.
The task board records what should happen. The application, code, logs, and relevant accounts tell us what has happened. A cheerful task comment is useful communication, but it cannot prove that a broken page now works. The final result returns to the original Asana task, which is marked done only when the requested outcome has been checked and no known blocker remains.
Let the request decide what work is needed
Once Codex takes the request, it reads the project’s instructions and checks the current state before making changes. It examines the relevant code and tests, preserves unrelated work, and uses a separate working copy when needed. The email starts the investigation; it does not replace one.
Some requests lead to a code change. Others lead to a finding, a checked setting, or a saved reply draft. An alert may turn out to need no repair. A request to prepare an email should end with a draft I can review. It should not quietly become permission to send it.
I also want routine work to move without repeated permission requests. Where I have already approved a specific kind of project release, the agent should carry it through. Spending money, changing account access, deleting important data, or taking another action outside those limits needs its own approval. The boundaries belong to the job and the account, not to the agent’s level of enthusiasm.
That balance takes work to define. Stop too often and I am still operating the system by hand. Give it vague permission to do anything and I have created a different problem. Clear, narrow authority lets it do useful work while keeping consequential decisions with the right person.
Check the change, then check the result
Substantial technical changes go through an independent review process. The implementing agent produces the change and runs relevant checks. A separate critic examines it. A fresh senior reviewer then assesses the original request and the exact proposed version without being handed the earlier reviewers’ conclusions.
Valid findings lead to corrections and another check of the affected work. If a release is authorized and needed, the process continues through deployment and live verification. The reviewers then get the evidence from the deployed result. A fix that passes locally can still fail where customers use it.
Those reviews help challenge the work; they do not make AI infallible. Separate agents can miss the same thing, and a passing test only covers what it checks. The original requirement and the observed behavior still matter. I want evidence I can inspect, rather than a small committee agreeing that everything looks lovely.
Routine business work gets checks suited to the action. A saved email draft needs the right thread, recipients, and wording. It does not need the same process as a production software change. Applying the heaviest review to everything would make the system very good at producing review work.
Other tools are solving this problem, too
There are already good approaches to this kind of delegation. OpenAI’s Symphony reads work from a task board, currently Linear in its specification, creates a separate workspace for each issue, and runs a coding agent against the task. Its open-source specification gives teams a foundation they can adapt. The shared idea is that a request should keep moving without a person manually opening every agent session.
Cursor Automations runs agents on schedules and events from tools such as Slack, Linear, and GitHub. Cursor describes a bug-report flow that checks for duplicates, creates an issue, investigates the code, attempts a fix, and replies in the original thread. It also describes a Rippling engineer gathering notes and tasks in Slack for an agent to organize alongside activity from other tools.
Devin Automations supports scheduled and event-driven work, including starting a session or sending information into an existing one. Its documentation includes queueing and usage limits. These are overlapping capabilities, not features I can fairly claim only my setup has.
I have not run a controlled comparison showing that Codex Inbox finishes more work, costs less, or makes fewer mistakes than those products. My reason for building it is fit: my email, my Asana board, my mix of development and business tasks, and my existing project rules. A packaged system may be a better choice for another team, especially if it already fits how they work.
Custom fit comes with maintenance
Owning the coordination between tools means owning its failures. A signed-in session can expire. A connector can be unavailable. A scheduled run can stop. A task can be left with the wrong status. The system needs a way to recognize unfinished work and resume it without creating a second, competing attempt.
The instructions also need care. They have to preserve the original request, keep private information out of public updates, and distinguish a new problem from the job already underway. If the agent finds something adjacent, that may deserve a linked follow-up rather than an unannounced expansion of the assignment.
I am still refining this. I am not claiming a measured saving of a certain number of hours or a system that never needs help. The standard I am working toward is concrete: fewer repeated explanations, clear ownership, a specific question when I am needed, and a result checked against what I asked for.
Build around the way your work arrives
For a small business, the same idea applies beyond software repairs. A customer question arrives, a quote needs follow-up, or someone spots a repeated problem on the website. The request needs its context, an owner, permission to take useful steps, and a clear finish. Better AI can help with those steps when it has the right information and tools.
That is also how we approach AI workers at Bombyx Labs. We start with the business’s knowledge, the work people already do, and the decisions they need to keep. In our guided calling work, people stay involved as a conversation unfolds. In Codex Inbox, they can set the task and its limits, then return when a decision or a finished result needs their attention.
Modern tooling gives us more room to shape that experience. You can use an existing product, connect tools you already have, or build a small amount around them. Start with one recurring request and decide how it should arrive, who should own it, what the assistant may do, and how you will know it is finished. You may discover that the best improvement is getting the tools to follow your working habits, instead of spending your day adapting to theirs.