I’ve gotten closer to creating “agents” with Codex. It’s still early, and they aren’t bootable or portable digital coworkers, but they’re closer to something that behaves like a persistent operating system.
The magic trick is Codex’s ability to create and message other threads while executing inside of a chat session. That allows us to create a series of threads that can be “woken” up on demand to execute a unit of work.
The full architecture ends up looking something like this:
Agent.face – This is the public surface of the agent and where other chats and agents interface with. Work requests and responses are routed through the “face” thread. It provides an acknowledgement of receipt and then delegates to internal sessions.
Agent.function – These are internal sessions that map to domains or functions the agent is responsible for. This could be something like a final review/critique before work products external to the agent. It could also be more of a task area like Jira hygiene and monitoring.
Capability Registry – This is similar to an API spec. It defines the IDs of the face threads, as well as a summary of functions, tasks, and domains each agent is equipped to help with.
As an example, new concepts from Slack can be identified by one thread and handed off to an explorer thread. The explorer looks for stronger context in places like Jira, Confluence, or related Slack history. If it finds enough authoritative source material, the findings can be forwarded to another thread to draft a new addition to an Obsidian knowledge base.
In a more complete version, this starts to look like an “agent mesh” where work can move between agents directly. They use this thread-to-thread messaging capability to send and track the requests needed to fulfill their tasks.
At that point, the real capabilities of the system are limited by how well-defined the agents are, how advanced the agent functions are, and whether the system can recognize when a handoff worked, failed, or needs human review.