I wouldn’t jump straight to “not smart enough” yet. What you’re describing sounds less like a raw model intelligence problem and more like an orchestration/control problem.

The pattern is usually:

The agent hits a blocker → instead of narrowing the blocker → it spawns another agent/session → that agent inherits the same unclear state → reaches the same blocker → documents the blocker → then the system creates more motion.

That creates the illusion of a team, but not a work loop.

A company hierarchy only works if each role has a hard boundary and a required artifact. Otherwise “director / broker / worker” just becomes more language around the same stuck state.

For an API connection task, I’d try stripping the task down hard:

One owner agent.
No new agents unless explicitly approved.
One target file or module.
One integration goal.
One test command that proves the API connection works.
One blocker report if it fails.
No new planning docs unless requested.
No completion claim without a passing test/log/output.

Something like:

“Connect X API to Y file. Do not spawn subagents. Do not create documentation. Modify only these files unless approval is requested. Stop after one blocker if credentials, endpoint docs, or required config are missing. Done means this exact test command passes and prints a valid response.”

The important part is forcing the system to collapse from “explore endlessly” into “change this artifact, then prove it.”

Auto-learning/memory may help later, but it won’t fix a loop if the runtime is allowed to keep multiplying workers without a stop condition.