Agentic engineering begins where generation changes state
The label grew out of attempts to turn language models from response generators into components that can act through software. The engineering problem is not autonomy for its own sake.
It is controlling a loop whose next step depends on a model judgment and whose actions may alter files, databases, tickets, or external services.
A chatbot can answer a question without being an agent. An agentic system receives a goal, selects an action, observes the result, and decides whether to continue.
That loop is the boundary between ordinary LLM application development and agentic engineering.
The adjacent terms describe parts, not the whole discipline
Tool calling is the interface that lets a model request an operation. Flow engineering defines a controlled sequence of model and program steps, while an agentic router chooses among destinations.
Agentic engineering covers the larger system: state, permissions, recovery, observability, evaluation, and the point at which a human must intervene.
Multi-agent design is also not a requirement. One model with a shell tool and a verification loop is agentic; five models that only debate before returning text may not be.
The loop needs explicit state and a bounded action set
An agent needs a state representation that distinguishes the goal, completed work, current evidence, and unresolved decisions. A transcript can contain that information, but it does not make the distinctions reliable or easy to inspect.
The action set should be narrower than everything the runtime can technically execute. Read access, mutation, external communication, and irreversible operations deserve different policies because their failure costs are not interchangeable.
Autonomy is an operating boundary, not a product label
The useful design question is what the model may decide without another approval. That boundary determines which actions need reversible execution, which observations need durable logs, and where the system must stop.
A narrow autonomous loop can be safer and more useful than a broad assistant that asks for vague blanket permission. Scope is part of the design, not an obstacle added after the agent works.
A repository repair shows what the discipline changes
Consider a coding agent asked to rename an API. The model can search for call sites, edit the implementation, run tests, read a failure, and correct the missed fixture.
The engineering work lies in limiting writable paths, preserving the test output as evidence, preventing an endless retry loop, and requiring a diff for review.
The agentic workflow playbook develops that example into a shipped-work process. Agentic engineering does not apply when a deterministic script already knows every step, and the common misuse is adding a planner or extra agent where ordinary control flow would be cheaper and easier to test.
Completion must be demonstrated outside the model
An agent saying that a task is complete is only another model output. Completion evidence comes from the environment: a passing pre-existing test, a clean diff against the requested scope, or a returned record that proves the external operation occurred.
A self-authored fixture does not close the loop because it tests the agent’s assumptions against a test built from those same assumptions. The verifier must have an independent reason to reject a wrong result.
Completion must be demonstrated outside the model
An agent saying that a task is complete is only another model output. Completion evidence comes from the environment: a passing test that existed before the change, a clean diff against the requested scope, or a returned record that proves the external operation occurred.
A self-authored fixture does not close the loop because it tests the agent’s assumptions against a test built from those same assumptions. The verifier must have an independent reason to reject a wrong result.
Continue with these glossary entries: