Engineering AI Agents

An agent is a model choosing actions in a loop that application code runs, so the first job is drawing the boundary between model decisions and deterministic application control. You trace one cycle from goal to observation, action, and environment feedback, then bound it with explicit stop reasons and step, token, time, and cost budgets. Planning extends that loop into task decomposition with verifiable subgoals, dependency-aware ordering, and replanning when an observation invalidates an assumption, with progress checks that catch stalled work before the budget runs out.

Tool calls are structured model outputs, and the application decides whether to execute them. That makes the tool portfolio the real safety surface: preconditions and postconditions form the enforceable contract, read-only versus reversible versus irreversible classification decides what needs an approval gate, and least-privilege credentials scoped to each tool cap the damage from a bad call. Prompt injection arriving through untrusted tool observations is contained at that same application-controlled action boundary, and dependencies between parallel actions are checked so conflicting actions never race.

Two kinds of state outlive a single model invocation. Memory splits into working context, episodic records, semantic facts, and procedural memory, each with write criteria, provenance, retrieval tied to the current goal, staleness and contradiction detection, tenant isolation, and retention and deletion boundaries. Execution state lives in an explicit state machine with persisted checkpoints, retry policies by failure class, idempotent actions, duplicate suppression, and compensating actions, so a run that dies halfway resumes without repeating an unsafe side effect or dropping the context a human operator needs to take over.

A single successful run proves little about a nondeterministic system. Evaluation here means asserting task outcomes, constraints, and side effects on recorded runs, then reading trajectories and tool selection alongside step, token, latency, and cost metrics. Stress tests inject tool errors and unavailable dependencies, adversarial cases probe instruction conflicts and unsafe actions, and repeated trial sets give you a measured success rate with a stated confidence, drawn from production traces under privacy controls.