Twelve tickets, one person, and an afternoon. You’re not writing any of this code — you’re assigning it. Ticket one goes to the agent: add a loading state to the export button. Small, contained, fire and forget. Ticket seven goes to the same agent: fix the flaky timeout in the webhook retry logic. You glance at it, think “about the same size as ticket one,” assign it the same way, move on.
Two hours later ticket seven comes back. The fix works. It also touches the shared retry queue that three other services depend on — and you didn’t know that until you read the diff, because you weren’t the one who went and looked. The agent was. It just didn’t tell you what it found until after it was done finding it.
This is the estimation problem nobody selling “agent orchestration” is actually talking about. Search the term and you get architecture guides about failure containment and enterprise risk dashboards. Nobody’s asking the smaller, dumber question: how do you size a ticket you’re not going to implement, before you hand it off?
For teams where a person still writes the code with AI assistance, this is already solved. A human votes on four questions before the ticket starts — steering effort, architectural impact, domain knowledge, review burden — because a person who’s touched the codebase can look at “fix the webhook retry” and think, correctly, “that queue is shared, this is bigger than it looks.” That’s what our AI Era config is built for: a human estimating an agent’s work from just outside it.
Pure orchestration breaks that setup, because you’re not just outside the code — you’re outside the ticket. You’re reading a title and making the same shallow guess the agent would make before it looks. Except the agent is about to actually look. It’s going to open the retry logic, trace what calls it, notice the shared queue. It will know architectural impact is high before it writes a line. You won’t know until it’s done.
So don’t estimate the agent’s work. Have the agent estimate it.
The four questions don’t change — they’re still the ones from AI Era, same names, same weights, no new config. What changes is who’s answering them. Instead of you guessing from a ticket title, the agent answers from having actually read the code it’s about to touch, before it writes a single line.
What changes isn’t the estimate. It’s when you get it. Ticket seven, answered honestly, comes back with architectural impact flagged high and domain knowledge flagged low — before the agent starts, not after you’ve already read a diff you didn’t expect. That’s not a bigger ticket than ticket one. It’s a ticket that needs you standing next to it while it works, instead of one you can hand off and forget. You know which is which before either one starts, instead of finding out for one of them the hard way.
That’s the actual shift agentic orchestration asks for. Not a fifth dimension, not a new scale — just moving the question to the one participant who already has the answer.
If you want to try this — create an AI Era session at Estimate Well and share the link with your coding agent instead of your team. We wrote up the exact four questions as a skill file you can point the agent at directly — it votes on itself before it starts. Free, no account needed.