How I run AI coding agents as a team with AI DevKit – Codeaholicguy

Skip to content

codeaholicguy

AI, ai-devkit, Software Engineering

08/19/202608/19/2026

9 Minutes

I spend most of my time in the AI DevKit agent console. I start one agent as the manager, usually Codex, and brainstorm with it. Once an idea becomes concrete enough to execute, I ask the manager to create another agent and hand off the work. That executor might run in Codex, Claude Code, Pi, or another harness depending on what I need.

The executor follows the dev lifecycle, implements the change, verifies it, and often creates the pull request without much intervention from me. I check progress with the manager instead of jumping between every agent session. When the pull request is ready, I review it, give feedback if needed, and merge it.

This is what lets me work on several things at the same time without turning my terminal into a wall of tabs.

I am not always at the keyboard either. When I step away, I connect the manager agent to Telegram and continue working with the same session from my phone.

AI DevKit gives me an agent manager, a shared operating model, and enough common context for different harnesses to work as one team.

I'm running Claude Code, Codex, and Gemini CLI in parallel.

The worst part isn't the token cost. It's the tab switching.

AI DevKit's Agent Console fixes this. One view, all your agents, send messages without leaving, quick hotkey to focus when you need detail.

Works in iTerm2,… pic.twitter.com/3VHg8LIUBa<br>— Hoang Nguyen (@codeaholicguy) May 28, 2026

The agent console

The main interface for me is the AI DevKit agent console.

The console gives me one place to open, message, and monitor agents across different harnesses. I can see what is running, which agent is waiting, and where I need to step in.

I still use commands such as agent list, agent detail, and agent send, but mostly for debugging, automation, or inspecting something the console does not make obvious. They are the low-level controls, not the center of my workflow.

I did not want a collection of commands that made me a faster dispatcher. I wanted an operating environment where one agent could manage other agents while I stayed focused on the problem.

The manager does more than route messages. It keeps track of the goal, the active workstreams, dependencies between agents, and anything waiting for a decision. It also checks whether an agent claiming completion has actually produced a verified result.

I also mentioned in the previous post why I have so many executor types. Basically, I want to make full use of my subscriptions while also taking advantage of what each executor is good at and being able to run different models.

The manager follows me to Telegram

The agent console is my main interface when I am at the computer. When I am away from the keyboard, I use the AI DevKit channel connector.

I select the manager agent in the console and connect it to my configured Telegram channel. The bridge runs in the background, so I can close the terminal view and keep talking to the manager from my phone. I also have the same AI DevKit stack running on a VPS so that I can chat with the agent manager 24/7.

Your AI agent no longer has to sit inside your terminal.

Pi integration is now available in AI DevKit.

Start a Pi session in Agent Console, or remote control it from Telegram with one click. https://t.co/tt6M4nhR3O pic.twitter.com/MRtHq4yhgz<br>— Hoang Nguyen (@codeaholicguy) June 13, 2026

This is still the same manager session. Telegram is simply another transport into it. The manager keeps its working context, access to the filesystem and memory, and the ability to coordinate executor agents.

From Telegram, I can ask for progress, answer a question that is blocking an executor, give feedback, or ask the manager to start another piece of work. I do not need to wait until I am back at my desk to keep the orchestration loop moving.

The equivalent low-level command is:

ai-devkit channel start telegram \<br>--agent \<br>--daemon

I normally connect it from the console. The command is useful when I am debugging the bridge or automating the setup.

I encode the workflow in skills

Anything I expect to repeat becomes a skill.

This is a large part of how I keep different harnesses consistent. Codex, Claude Code, OpenCode, Pi, or any different harnesses have different capabilities and session behavior, but they can load the same engineering process from the repository.

The skills I use heavily for this workflow are:

agent-management for starting, selecting, inspecting, and stopping agents safely

agent-communication for sending assignments, reading recent context, and relaying results between agents

agent-orchestration for the repeated supervision loop: check progress, unblock agents, coordinate dependencies, and verify completion

dev-lifecycle for moving a change through requirements, design, planning, implementation, testing, and...