From Vibe Coding to AI Workflow: What Controls an Agent?

What is an AI agent, really?

There is no single definition of an agent that works the same way in every tool. For this post, a good starting point is the definition from OpenAI: The key word in that definition is "configured". An agent still relies on an LLM, but it is not just the model. It is the model running with a specific configuration in a specific runtime. That configuration can include the chosen model, instructions, working mode, available tools, constraints, expected output and the rules for moving between steps. The runtime handles the rest: it assembles the input for the model, attaches instructions and context, handles tool calls, passes tool results back to the model and maintains session history. So an agent is not just a "better prompt". The prompt is only one of many inputs. What determines how an agent works is the combination of model, configuration, runtime, available context, tools and constraints.

Agent as a concept, not an implementation

I do not treat an agent here as a specific file, a mode in an IDE or a feature of one tool. The same mechanism can be packaged differently in Copilot, Claude Code or an application built directly on the SDK. File names, modes and settings will differ, but the underlying problem is the same: how to control the model's work, context, tools, constraints and output.

What shapes an AI agent's work?

Several groups of elements shape how an agent works. This is not an official taxonomy from any one tool's documentation. It is a practical model that helps check whether an agent has the right configuration, the right context and clear work boundaries.

Agent configuration

These elements define how the agent works, regardless of the current task.

• Model - You may use one model for exploration, another for implementation and another for architecture review. The choice affects cost, speed and reasoning quality.
• Role and responsibility - The agent should have a defined role: whether it explores, prepares a spec, implements, reviews code or simply answers a question.
• Standing instructions (system instructions / system prompt) - Rules that always apply or apply to a given type of work: architectural requirements, test style, project conventions, communication style and output formatting rules.
• Context discovery rules (context discovery / retrieval guidance) - Guidelines defining where the agent should look for missing information, what sources to use and when to stop exploring.
• Tools and permissions (tools / tool definitions) - Access to files, editing, terminal, tests, MCP, APIs or other sources. The LLM itself does not perform these actions. That is the runtime's job: it exposes the tools and enforces part of the constraints.
• Expected output - A definition of what the agent should leave behind: code, a spec, a summary, a verification result or material for the next step.

Task-specific input

These are things the agent receives at the start of a given task.

• User prompt - The current request: what needs to be done now.
• Task context - A ticket, acceptance criteria, bug description, open files, current diff, spec or a previous artifact.
• Local instructions - Rules that apply only to this task: for example, the scope of the change, constraints or areas that should not be touched.
• Handoff from the previous step - Input material produced earlier: a spec, exploration summary, review notes or the output of a previous session.

Context retrieved during work

These are elements the agent does not need to know at the start, but can find or receive during execution. In agentic systems, this is closer to retrieved context and tool observations than to a manually prepared prompt.

• Files and documents (retrieved context) - Code fragments, documentation, configuration files, tests or other materials read during the task.
• Tool results (tool results / observations) - Results from searches, commands, tests, builds, linters or external APIs.
• Errors and constraints discovered along the way - Missing dependencies, code inconsistencies, outdated documentation or edge cases not mentioned in the original task description.

Output and artifacts

What the agent creates or leaves behind.

• Project changes - Code, tests, configuration, documentation or other modified files.
• Summaries and notes (working notes / intermediate artifacts) - Implementation summary, decision notes, exploration summary, review findings or the result of an analysis.
• Handoff artifact - Output prepared to become the input for the next step, agent or session.

Guardrails and verification

These are elements that constrain the agent's work or check its results.

• Guardrails - Rules defining what the agent should not do or what requires approval: restricted files, destructive commands, public API changes, access to sensitive data, operations outside the task scope.
• Technical verification - Tests, build, lint, typecheck, schema validation or other automated checks.
• Requirements and architecture verification - Acceptance criteria, architecture review, alignment with requirements and project decisions.

The point is not to immediately turn each of these elements into a separate file, agent or process. In a small task, some of them can exist only within a single conversation. In a larger workflow, separating them matters - otherwise it is easy to confuse project rules with task data, discovered context with a design decision, and final output with material for the next step.

How an AI agent actually works

With these elements defined, let's see how they operate in practice. An agent does not operate as a single, continuous stream of reasoning. In practice, it is a loop between the runtime, the model and the tools. The runtime is the control layer: a CLI, IDE, web application, agent framework or a custom script. It is responsible for the technical side of the agent's work: preparing the input for the model, handling tools, passing results and enforcing part of the constraints. In simplified form, it looks like this:

1. The runtime assembles the model input. It takes the agent configuration, task input, available context, session history and descriptions of the tools the agent can use.
2. The model analyzes this state and generates the next step. It can respond with text, propose a change or return a tool call request.
3. If a tool is needed, the model does not perform the operation itself. It returns a structured tool call to the runtime - for example to read a file, search for a code fragment or run tests.
4. The runtime executes the action outside the model. It reads the file, runs the command, calls the API or uses MCP. The runtime also enforces permissions and can stop the operation if it goes beyond the allowed scope.
5. The tool result goes back into the next step. The runtime adds it to the context and sends the next input to the model. From this point, the model can work on new information: the retrieved file, a test failure, a search result or a command log. The loop starts again.

The loop continues until the agent produces the expected output or is stopped by the runtime, a step limit, a tool error or a guardrail. In interactive tools, stopping may mean asking the user a question or requesting approval. In non-interactive mode, it may end with an error, a fallback or task termination. The context window has a finite size. The runtime cannot keep adding more files, logs and tool results without limit. That is why agent work depends not only on tool access but also on selecting what goes back into subsequent model calls. The LLM does not have its own access to files, a terminal or project memory. It receives a text context prepared by the runtime. If the agent "remembers" what happened earlier, it is because the runtime passed it the conversation history, a summary or the results of previous steps. That history can be thought of as short-term session memory (conversation history / short-term memory). Explicit artifacts such as specs, summaries or handoff files are something different: they are workflow state (state management) that can be carried over to the next session or the next agent. If the agent "uses a tool", it is because the runtime exposed that mechanism and performed the operation on its side. This loop is what distinguishes agent work from a single chat response. An agent does not just answer a prompt. It can iteratively gather context, perform actions through tools, analyze the results and only then prepare its output.

Context flow, not just input

With the runtime loop in mind, the agent's context is clearly not static. With each step, it can grow by adding files, tool results, logs, errors, recorded decisions and artifacts from previous steps.

The risk is that wrong or irrelevant context can pollute the entire session and affect the agent's subsequent decisions. If during exploration the agent treats a random implementation as the accepted pattern, reads outdated documentation or skips an important part of the domain, the error can get locked into the first artifact. The spec will then be based on wrong context. The implementer may faithfully implement that spec. The reviewer may check the diff against the plan and not notice the problem, because the code will match the flawed assumption. Without verifying artifacts between steps, such an error can propagate through the entire flow. This is why working with agents is not about "giving more context". It is about controlling the quality of what actually reaches the agent: the input, exploration results, partial summaries and forwarded artifacts. Each of these elements can help the agent make a better decision, but it can also lock in an error and carry it to the next step. In practice, this means two things:

• Input should match the agent's role. A spec writer needs different information than an implementer, and a reviewer needs different information than an explorer. Dumping everything into every agent may feel safe, but it often adds noise and burns through the context window without real benefit.
• Exploration must have boundaries. The agent should know where to look, what to look for and when to stop. Without that, it can read a lot of files, find accidental similarities and build conclusions on material that has nothing to do with the task.

In an agent workflow, context quality matters more than quantity. Every subsequent step builds on what was provided, found or passed earlier, so weak context can compromise the result even when the loop itself looks correct. This is the practical version of a problem well known from working with LLMs: context degradation and losing important information in a large context window.

Output, artifacts and handoff

Since an agent works in a loop, its output is not just a final answer. In larger tasks, output often serves two roles: it is the result of the current step and at the same time the input material for the next one. The most obvious output is code, but intermediate artifacts are equally important in agent work. The goal is not documentation for its own sake. An artifact should help the work continue, not just look like a trace of something that was done. In practice, an artifact should do at least one of three things:

• Support human review - A good artifact shows things that can be quickly checked: decisions made, assumptions, example API requests, an algorithm diagram, a list of changed areas or edge cases the agent accounted for.
• Be a precise input for the next step - A good artifact should reduce the need to reconstruct the conversation history. The next step should receive clear input material, not have to guess what was agreed earlier.
• Support control within a standard SDLC process - An artifact can contain test results, verification status, a list of unmet acceptance criteria or a clear approve/reject recommendation. This makes it easier to stop a change during review, in CI or before merge, instead of pushing a flawed output further.

Handoff happens when the output of one step becomes the input for the next. A spec can be a handoff for the implementer. A diff and test results can be a handoff for the reviewer. An exploration summary can be a handoff for the next session. In a small task, that handoff can be informal and exist only in the conversation history. That is often enough. Problems start with longer or riskier changes. In those cases, an explicit artifact is safer - it can be read, corrected, approved and used in a new session without relying on the conversation history from a previous session. An artifact makes sense only when it helps check something, pass it forward or stop it in the process. If nobody reads it and no subsequent step actually uses it, it is not a workflow control element - it is just extra text in the context.

Start simple

It is easy to over-design the workflow on day one. When you have agents, tools, handoffs, guardrails and artifacts, it is tempting to design the whole process at once: an analysis agent, a spec agent, an implementation agent, a test agent and a review agent. But that often does not solve the problem. Sometimes it just moves the chaos from one prompt to several named agents. Usually, one agent or one simple working mode is enough to start. That agent can prepare a change, run tests and do basic self-review. In a small task, that is often sufficient. What matters more than the number of agents is whether the agent has clearly defined:

• what role it has,
• what rules it should follow,
• where to look for missing context,
• what it should not do,
• what it should leave behind,
• how the result should be checked.

The right time to split the workflow is when the simple setup introduces friction. If analysis requires browsing a large codebase, separating exploration or spec writing helps - the implementer does not start by chaotically reading through the repository. If review is too shallow, a separate review agent or review mode can help. If every session reads the same files over again, leaving an explicit exploration summary or handoff file usually helps. That is the pragmatic line: do not build workflow for the sake of workflow. Add structure only when it solves a real problem.

Summary

An agent does not guarantee quality just because it runs in agentic mode. Under the hood it is still an LLM, so the result depends on the quality of context, instructions, tools and verification. The whole point of configuration, runtime, artifacts and handoffs is to make AI work more controllable. We want to know what the agent received as input, what it found, what it left behind and where we can stop an error before it propagates further. There is no need to start with a complex agent system. A simple but deliberate setup is enough: a clear role, sensible input, bounded exploration, readable output and basic verification. Adding more roles, handoffs and artifacts makes sense only when the simple setup causes friction.