ai-agent-engineering

Design the tools/functions an agent calls and the context/memory strategy that keeps it coherent — unambiguous tool names, typed parameters, examples-in-description, errors that teach recovery, a small-enough tool count, plus a context plan (what stays in-window, what gets summarized, what moves to external memory) and short-term-vs-long-term memory design under a per-turn token budget. Reach for this when the user says 'the agent keeps calling tools wrong', 'the context overflows', or 'the agent loses track on long runs'. Used by `agent-implementation-engineer` (primary).

Evaluate an agent and harden its failure modes before it touches real traffic — an offline eval harness scored on task-completion, trajectory, and tool-use correctness against a fixed task set, plus loop hardening (step/tool-call caps, timeouts + retries, stop conditions, human-in-the-loop on irreversible actions) and tracing so every step/tool-call/token-cost is observable, with cost and latency reported alongside quality. Reach for this when the user asks 'how do I know this agent works?', 'set up agent evals', or 'the agent loops / does something dangerous'. Used by `agent-implementation-engineer` (primary).

Decide whether a task should be an agent at all — and if so, single-agent vs multi-agent, the orchestration topology, and the framework — by traversing the agentic decision tree (agent-vs-workflow gate → single-vs-multi → topology → framework), returning a go/no-go verdict that defaults to 'a fixed workflow or a single LLM call wins' unless the control flow is genuinely unknowable in advance. Reach for this when the user asks 'should we build an agent for this?', 'do we need multiple agents?', 'LangGraph or CrewAI or the OpenAI/Claude Agents SDK?', or 'is this an agent or just a workflow?'. Used by `agentic-systems-architect` (primary).