Jan Mikoláš
Glossary
AI agent
An agentic workflow connects a model to restricted tools and feedback from their results. Its value comes not from the promise of autonomy, but from a well-defined task, permissions, and checkpoints.
Short definition
A model that can proceed using tools and their results.
In current AI development, an agent usually means an application in which the model does more than return a single answer. It receives a goal, instructions, and context, can choose a tool, read its result, and continue with another step. Orchestration defines the limits and when to stop.
A model alone is not an agent: it does not know the actual state or permissions of an external system. The surrounding application defines the context, allowed calls, argument validation, and error behaviour. Memory or planning may help, but neither is a mandatory property of an agent.
The problem it solves
Tasks where one fixed procedure is not enough.
An agent makes sense when the next step reasonably depends on information discovered along the way, while the boundaries of the work can still be described and controlled.
- exploring a repository structure before making a small, verifiable change
- classifying and preparing drafts from a larger set of documents
- retrieving data through a read-only tool and preparing a summary for a person
- diagnosing an error from logs, tests, and predefined commands
- a multi-step process that must respond to an incomplete result or tool error
- preparing a change that a responsible person approves before execution
Practical example
Preparing a new API endpoint in a PHP project
A developer gives a limited task: add an endpoint for displaying an order, without deployment or production access. The agent reads the repository rules and similar endpoints, prepares the change in a dedicated working copy, and runs tests. If a test fails, it fixes only the relevant part within the defined limit.
After success, it runs static analysis and presents the diff together with the check results. A migration, submitting the change, or modifying production remains a separate action requiring explicit approval. This is one possible workflow, not a guarantee of sound design.
How it works
Text flow: goal → choose a step → tool → observation → check → result or stop
The flow is intentionally short and readable on mobile. Context, instructions, and application permissions constrain every step.
- Goal and boundaries The user defines the task, prohibited actions, and confirmation points.
- Context The application passes only the data needed for the current step.
- Proposed step The model proposes a response or allowed call; the orchestrator validates the arguments and policy.
- Tool execution The tool reads a file, runs a test, or performs another permitted operation, not an unrestricted system action.
- Observation and validation The result is data for the next step, not a trusted instruction.
- Stop or handoff When the goal is met, a limit is reached, or a sensitive action approaches, the workflow ends or hands the proposal to a person.
Main components
Each component has a different responsibility.
Reliability does not come from model capability alone. It depends primarily on what the application permits, validates, and records.
Model
Proposes the next output or use of a tool. Its response is neither a verified fact nor permission to act.
Instructions
Define the purpose, work order, result format, and boundaries.
Context
The data and documents available for a step; excess context increases both cost and leakage risk.
Tools
Specific interfaces for reading or acting, each with a narrow purpose and verifiable inputs.
Orchestration and limits
Control steps, budget, timeouts, retries, and stopping conditions. A plan should not replace a simple procedure.
Human oversight
A person approves sensitive or irreversible operations and assesses the result.
Benefits and limitations
A useful workflow, but not an independent worker.
When it can help
- combines exploration, a proposal, and repeated checks into a traceable workflow
- can respond to a tool result instead of requiring a fixed scenario for every variant
- relieves people of mechanical steps when those steps remain well constrained
- can run the same quality gates consistently before handing off the result
Limitations and common mistakes
- the model may misinterpret the task, data, or tool result
- a long chain of steps increases cost, latency, and room for error
- a broad tool that can “do anything in production” defeats the purpose of security boundaries
- replacing simple automation with an agent complicates operations without corresponding value
Pragmatic use
Define the boundaries first, then add autonomy.
A script or form is usually better for a repeatable process with fixed steps. An agentic approach makes sense when the next step depends on ambiguous input. A good starting point is one narrow use case with read-only access.
Quality is not determined by the number of steps. Measure outcome scenarios, errors, human interventions, and costs. Limits on actions and retries prevent cycles of similar but unhelpful changes.
Security and control
Trust neither the model nor tool content automatically.
A secure design separates reading from writing, limits the impact of an error, and gives people visibility into what actually happened.
- give each tool the minimum permissions it needs and separate read-only access from writes
- treat websites, emails, files, and tool outputs as untrusted data that may contain prompt injection
- require human confirmation before payments, publication, permission changes, deletion, and other sensitive actions
- validate tool arguments, restrict paths and commands, and use a sandbox for code of uncertain origin
- record significant calls and verify proposed changes with tests, static analysis, and CI
Common questions
What to expect from an AI agent
Is every chatbot an AI agent?
No. An agent manages multiple steps or tools within a defined workflow; a chatbot may only generate responses.
Is an agent autonomous?
Only within the workflow. Multi-step work does not implicitly grant access to email, a database, or production.
Can prompt injection be solved with better instructions alone?
No. Tool permissions must also be restricted, data validated, environments isolated, and sensitive actions confirmed.
Does an agent need memory and a plan?
No. They are added only when they solve a specific problem beyond the current step and a simple tool–result loop.
How I use AI in development
AI is useful when its work can be verified.
I use AI in development for exploration, proposals, and verifiable steps; decisions that affect the project remain under human oversight.