“Should I hire a full-stack agent developer or a specialist” is the wrong first question. The right one is which layer of the agent stack your project actually touches, because specialist value doesn't apply uniformly across an agent system. It concentrates at specific layers and is close to irrelevant at others. Here's the stack broken into four layers, from the ground up, with where a generalist is fine and where you actually need depth.
Layer 1: Tool-Use / ReAct — generalist territory
A tool registry, a reasoning loop, and retry/error handling around LLM tool calls. This is the layer every framework tutorial covers and every full-stack developer should be able to build without help. The bar isn't whether they've used LangChain, it's whether they've handled the boring parts: what happens when a tool call times out, what happens when the LLM tries to call a tool that doesn't exist, what the fallback response looks like.
Generalist territory: a tool-use layer any full-stack dev can own
TOOLS = {
"lookup_order": lookup_order_status,
"update_crm": update_crm_record,
"search_docs": search_knowledge_base,
}
def run_agent_step(query, history):
plan = llm.plan(query, tools=TOOLS.keys(), history=history)
if plan.tool_call:
try:
result = TOOLSplan.tool_call.name
except ToolError:
return fallback_response(query)
return llm.respond(query, tool_result=result)
return llm.respond(query)
If a candidate's version of this has no try/except around the tool call and no fallback_response, they've built a demo, not layer 1 of a production stack.
Layer 2: RAG / Retrieval — depends on data complexity
This is the layer where the generalist-vs-specialist line actually moves depending on the project, not a fixed rule. A single clean, well-structured knowledge base with a few hundred documents is a full-stack build: pick a vector store, chunk reasonably, ship it. Five heterogeneous data sources with different schemas, update frequencies, and retrieval requirements is a different problem, chunking strategy, reranking, hybrid search, and retrieval evaluation become the primary engineering challenge, and that's where a RAG specialist's marginal value shows up in benchmarked retrieval precision, not vibes.
Layer 3: Multi-Agent Orchestration — specialist territory
Once you have an orchestrator coordinating specialist subagents with shared memory, the failure modes change category entirely. It's no longer “did the tool call work,” it's “did agent B act on stale state agent A hadn't finished writing yet.” Designing role boundaries, a coordination protocol, and shared memory architecture that doesn't produce race conditions or duplicated work requires having actually debugged a multi-agent coordination failure before, not having read about the CrewAI or AutoGen pattern.
Layer 4: Autonomous / Reflection — specialist territory
Planner, executor, and a reflection loop over persistent state is the highest-complexity layer and the one most reliably underestimated by developers who've only shipped single-task reactive agents. The engineering problem here isn't prompting the LLM to reflect, it's defining a completion criterion precise enough that the agent doesn't loop indefinitely or terminate before the task is actually done, and building the state persistence that lets it resume correctly across sessions.
Reading the stack for a hiring decision
A project that only ever touches layers 1 and 2 with a simple data source is a full-stack hire, full stop, bringing in a multi-agent specialist here adds coordination overhead without a corresponding capability gain. A project that lives at layers 3 and 4 needs someone who has specifically debugged coordination failures and reflection loops in production, a full-stack generalist's experience ceiling falls short of what those layers actually demand. The layer your project touches, not the job title on the contract, is the variable that should drive the hire.
This is a companion piece to the full hiring decision framework on shreyans.tech, which covers cost ranges, a six-use-case decision map, and verification questions to ask before you hire either.
Top comments (0)