How to Curb GPT's Ambition to Become a Leader

Codex
1

I built a multi-agent workflow primarily using the agent-team feature in Claude Code.
Given the project’s complexity—and the fact that I have comprehensive documentation—I organized the agents into three tiers, with specific “domain owners” responsible for their respective areas.
The main agent’s role is simply to activate them and monitor the process for any issues.

I clearly outlined everyone’s responsibilities in agent.md and workflow.md, explicitly stating that the main agent should not assign tasks to sub-agents or define their scope.
Yet, every time I start a new session, unless I specifically reiterate these points, the agent invariably assigns tasks to those owners.
I’ve revised the instructions countless times; this information is repeated across multiple documents.

But it insists on grandstanding with its own “insights” and assigning tasks to the sub-agents anyway.

2

I am still learning how to use this and have only used it once so far. However, the task ran for seven hours without drifting and completed without hallucinations. The final completion reason was a hard failure, caused by not allowing the AI to download and install code.

/goal — Gives Codex a persistent target to track while a larger task runs.

Additional references:

There is still a lot more to learn about /goal and long-horizon tasks. My suggestion would be to use it on a real-world project; learning by doing will likely be faster and more useful.

3

Anyone can get it to run continuously for 7 hours—I’ve even run it for 20.
But what is the point of running it for such a long time if you aren’t following instructions?
It’s not as if everyone is performing the exact same task, is it?

4

The 7-hour run did follow the instructions.

One of the hard-failure conditions was that the AI should try to resolve all human-in-the-loop questions itself, but stop if it reached a question or requirement it could not resolve.

In this case, the AI decided it needed to compare two PDF files using a tool that was not installed. Because the prompt was run with “Approve for me” rather than “Full access,” it was not allowed to install the required tool. At that point, it stopped.

I consider that a correct failure mode: it followed the instructions, reached an environment/permission limit, and stopped rather than working around the constraint incorrectly.

5

I don’t need it to solve any problems. I need it to follow my instructions. When using a agent, don’t add anything yourself; it doesn’t need to bypass any issues because the first output already shows it. Not following instructions is already a failure, and no one is restricting it.

6

Hi!

My suggestion: look into codex exec.

I have not encountered this specific issue yet because my setup works the other way around. I always assumed that the main agent passes in the instructions.

Off the top of my head: if I did not want that behavior, I would create a tool that calls codex exec in the CLI without giving the spawning agent the option to pass instructions to the new agent.

We always have to pass an initial message to get the agent started, but that prompt could come from the tool rather than from the agent that spawns the other one.

The main agent would then be instructed to use the tool instead of spawning another agent directly, which should circumvent the issue you are running into.

7

In my opinion, there is no ambition problem here. Your instructions contradict each other, and the model does its best inside that contradiction. What you see is expected behavior, not disobedience.

Let’s look at the facts.

An agent is built to receive a task and solve a problem. That’s the base layer. Your agent.md sits on top of it, it doesn’t replace it.

You named it the “main agent”. The word main means supervisor. Congratulations, you hired a manager and now you are surprised it manages.

You wrote its role is “simply to activate them and monitor the process”. Now the fun part: activating a sub-agent IS assigning a task. You cannot spawn an agent without passing it an initial message, and that message is a task by nature. And “monitor for issues” means evaluating the work, which means having opinions about it. There are your “insights”. So your instruction reads: “delegate and supervise, but don’t delegate and don’t supervise”. The model cannot satisfy both, so it picks the side that matches its base behavior. Every single time.

One question, because it’s not clear from your post: is that one agent.md where all roles are defined together, or does each sub-agent have its own file loaded only in its own context? If it’s one shared file, you made it worse. You gave the main agent the full org chart of who owns what, in its own context, and then told it not to think about it. It will think about it.

The session resets are also normal. Context is not memory. Whatever you negotiate inside a session dies with the session. Only the files survive. If the files contain the conflict, every new session starts from the conflict.

How I would fix it: decide where task definitions come from at runtime. If not from the main agent, then from pre-written task files or a script that spawns sub-agents with fixed prompts the main agent cannot touch. If you don’t want the model to make a decision, remove the decision from its hands instead of forbidding it with prose. And rename the thing. If it’s a launcher and a watcher, call it a dispatcher, describe only that job, and keep the other agents’ responsibilities out of its context.

The model follows your instructions perfectly. That’s the problem.

8

Thanks everyone for such an informative discussion. This is exactly the kind of constructive conversation that makes the community valuable.

There are a lot of helpful perspectives and practical tips here that will be useful not only for the original poster, but for anyone who comes across this thread later.

We'll keep this thread open so members can continue sharing their experiences and suggestions. If anyone has new insights or examples to add, please keep the discussion going.

-Mark G.

9

Thank you, your insights are very valuable, I will try them.

10

Feel free to show this thread and my previous message to your agent in the code base and ask it to analyze the conflicts in the instructions, provide you a detailed report about the overall state of the instructions and how the current state compares to the best practices for coding agents orchestration.