CCAR-F · Agentic Architecture
Task decomposition, fixed or dynamic
There are two ways to split a large task: decide the steps up front, or let the agent discover them as it goes.
Fixed pipeline
A fixed pipeline, which the guide calls prompt chaining, is a sequence of steps defined up front where each one receives what the previous one produced. It fits when you already know what needs doing, even if it’s a lot, such as a review with several predictable aspects. The size of the work is not the same as uncertainty: reviewing 200 known files is still a fixed pipeline.
Dynamic decomposition
Dynamic decomposition fits when you don’t know what you’ll find, for example in an undocumented legacy codebase. It needs an anchor, because otherwise the agent keeps discovering new work and never finishes:
- a clear goal;
- completion criteria;
- an explicit task list that the agent reprioritises as it finds new things.
Removing the iteration limit doesn’t fix it, and an arbitrary cap on steps stops it with no sense of priority.
Hybrid
Often the best option combines both: investigate dynamically and, once you know what has to change, apply the fix with a fixed pipeline.
Multiple passes
If an agent reviews many items at once and quality drops, it may be attention dilution: analyze each file separately and then run a separate integration pass that looks at issues spanning files. Feeding that pass what the per-file analysis produced (interfaces, exports, data flows) instead of all the code can help, but it is not a rule from the guide: what the guide asks for is separating the per-file analysis from the cross-file pass.
Watch the diagnosis: if quality is still equally poor when reviewing one item at a time, it wasn’t dilution. The problem is the criteria, the examples or the model’s capability.
In the exam
First ask whether the work is known up front. Then check whether the dynamic option has a goal and a criterion to finish.
Quick question
A practice exam question on this domain. It counts towards your progress.
A recruitment platform runs an agent that searches its internal candidate database and public profiles to shortlist applicants for open roles. It worked well on the team's test set of 150 job descriptions.
In production, however, the agent occasionally runs for dozens of iterations, repeating near-identical searches with tiny variations in the query. These runs are rare, a few a day out of several thousand, but each one is slow and expensive.
The developer has confirmed that the loop already branches correctly on stop_reason: it continues on "tool_use", finishes on "end_turn" and handles the other values separately.
The team is also planning to move the candidate database to a new search engine next quarter, although nothing about the runaway runs suggests the database itself is failing.
Which change is the most appropriate?