A housing authority builds an ADK-based eligibility agent that composes multiple typed tools, an income calculator and a document checker, rather than relying on a single monolithic prompt to handle the whole eligibility decision. What does this reflect about custom agent development with ADK?
Select an answer to reveal the explanation.
Short Explanation
Think of it like building with separate, labeled Lego pieces instead of carving the whole eligibility decision out of one solid block. Each ADK tool, the income calculator, the document checker, does one clearly defined job the agent can call directly, instead of hoping a single giant prompt reasons its way through everything at once. That's the actual shift ADK represents: code-defined, typed tools instead of one big prompt trying to do it all.
Full Explanation
Custom agent development with ADK is built around defining discrete, typed tools or functions with explicit inputs and outputs that the agent invokes as needed, which is a fundamentally different approach from the prompt-and-instruction configuration used in low-code tooling like Gemini Enterprise's agent designer. Composing an income calculator and a document checker as separate tools lets each piece of logic be tested, versioned, and reasoned about independently.
Avoiding multiple tools whenever a single prompt could plausibly cover the same logic reverses the actual design principle: a monolithic prompt is harder to validate and more prone to silently skipping a step, which is precisely what typed tools are meant to prevent. Treating typed tools as purely a readability aid ignores that their typing enables the agent runtime to validate inputs and outputs at call time, which does affect behavior, not just code clarity. Assuming tool composition only matters when the model is too small misunderstands the pattern, since even a highly capable model benefits from offloading deterministic calculations, like eligibility math, to a dedicated tool rather than reasoning through arithmetic in free text.
Scope note: over-decomposing into too many narrow tools can add unnecessary orchestration overhead, so tool boundaries should map to genuinely distinct responsibilities. Operational check: verify each tool's input and output schema independently before wiring it into the agent's overall eligibility workflow.