{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidee2r7ondw4wimjiuvljxoudmbynlypdfni4roctwkpjfw32nq5i",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mptxb662d7s2"
  },
  "path": "/t/how-to-curb-gpts-ambition-to-become-a-leader/1385720#post_7",
  "publishedAt": "2026-07-04T20:03:29.000Z",
  "site": "https://community.openai.com",
  "textContent": "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.\n\nLet’s look at the facts.\n\nAn 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.\n\nYou named it the “main agent”. The word main means supervisor. Congratulations, you hired a manager and now you are surprised it manages.\n\nYou 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.\n\nOne 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.\n\nThe 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.\n\nHow 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.\n\nThe model follows your instructions perfectly. That’s the problem.",
  "title": "How to Curb GPT's Ambition to Become a Leader"
}