In a CrewAI CrewBase project, how do agents.yaml and the @agent decorator define an Agent?

## Why the split exists Agent definitions are two very different kinds of thing wearing one constructor. `role`, `goal` and `backstory` are prose that changes often, benefits from review and reads badly inside Python string literals. `llm`, `tools` and callbacks are live objects that cannot be serialised into a config file at all. The scaffolded CrewAI project layout splits them along exactly that line: text in YAML, objects in Python. ## The YAML side `config/agents.yaml` is a mapping from an agent name to its fields: ``` researcher: role: > {topic} Senior Research Analyst goal: > Find and verify the three most significant recent developments in {topic} backstory: > You check claims against primary sources and say so when none exist. ``` The top-level key (`researcher`) is the lookup name used from code — it is not the role. YAML block scalars (`>`) keep long prose readable without escaping. Only serialisable fields belong here: the three prompt strings, and simple flags like `allow_delegation`, `max_iter` or `verbose` if you prefer them in config. ## The Python side The crew class is decorated with `@CrewBase` and declares where its config lives; each agent is a method decorated with `@agent`: `@agent` `def researcher(self) -> Agent:` ` return Agent(config=self.agents_config["researcher"], tools=[search_tool], verbose=True)` `Agent(config=...)` unpacks the YAML mapping into the constructor's fields; anything you also pass explicitly is set alongside it. This is where the objects go: the `LLM` instance, the tool list, a `step_callback`. ## What the decorator buys `@agent` is not decoration. It marks the method as producing one of the crew's agents so that the `@CrewBase` machinery can collect them, which is why the crew definition can pass a collected list of agents rather than naming each method. The practical effect is that adding an agent is one YAML block plus one decorated method — no third place to update, and no chance of defining an agent that the crew silently never receives because you forgot to add it to a list. ## Interpolation Placeholders written as `{topic}` inside the YAML strings are filled from the `inputs` dictionary supplied when the crew is kicked off. That is what turns a static persona into a per-run one, and it means the set of placeholders across your YAML files is effectively the crew's input contract. A placeholder with no matching key fails at run time. The corollary is worth stating out loud in an interview: braces in YAML prompt text are not inert, so literal braces in an example you want the model to see need care. ## The tradeoffs What you gain: prompt text becomes reviewable in a diff by someone who does not read Python, non-engineers can propose wording changes, and the same code can be pointed at a different config. Prompt iteration stops being a code change in spirit even when it is one in fact. What you pay: the YAML has no schema enforcement in your editor. A misspelled key inside an agent block is not applied and does not warn; a misspelled top-level name raises only when the lookup runs; a placeholder typo raises only at kickoff. Type checkers cannot see through the config dictionary into constructor fields either, so the usual advice is to have at least one test that constructs the crew and asserts each agent's role is what you expect — cheap insurance that turns a run-time surprise into a build failure. ## When to skip it For a single-file experiment or a crew built dynamically from user input, plain Python `Agent(...)` calls are clearer than a config indirection with one consumer. The YAML layout earns its keep when prompts are long, revised often, or edited by people who should not be in the code — which describes most crews that reach production. ## Interview framing Describe the split (text versus objects), name the three moving parts (`agents.yaml`, `agents_config` on the `@CrewBase` class, the `@agent` method that constructs the agent from the entry), and mention interpolation from kickoff inputs. Then be honest about the cost: unchecked keys, run-time-only errors, and the test you write to compensate.