Two Zarego Sessions explored the foundations of AI agents—and put them to work on a real software experiment.
AI coding tools are often described as faster autocomplete. That description is already too small. The more meaningful change is the emergence of agents: systems that can inspect a project, decide what to do next, use tools, modify files, run commands, test their own work, and continue toward a defined goal.
In two recent Zarego Sessions, our team explored that shift from theory to practice. The first session broke down how agents work and why context matters so much. The second turned those ideas into an experiment: building a simplified, Kahoot-style multiplayer application using AI agents, language models, and Model Context Protocol (MCP) servers.
The result was useful precisely because it was imperfect. It showed us where agents can accelerate development, where they lose direction, and why experienced developers remain essential—not mainly as code producers, but as architects, reviewers, and designers of the environment in which the agent works.
Watch Part 1: Introduction to AI Agents and Tools
[
The first session introduces the concepts behind AI agents, including models, tools, context windows, memory, and MCP.
An Agent Is More Than a Model
A large language model is the reasoning engine, but it is not the entire agent. On its own, a model receives input and generates output. An agent wraps that model in a system that can perceive its working environment and take action within it.
In software development, those actions may include reading files, searching a repository, editing code, installing dependencies, executing terminal commands, running tests, or consulting external documentation.
The agent coordinates the loop: it sends the relevant context to the model, interprets the response, invokes the appropriate tool, observes the result, and decides what information should be sent back next.
This distinction matters because the model does not independently remember a project. What appears to be memory is usually a managed collection of chat history, project files, instructions, summaries, and retrieved information. The quality of the agent’s work therefore depends heavily on what enters that context—and what stays out.
Context Is an Engineering Resource
A context window is finite. Every instruction, code file, response, and piece of documentation consumes tokens. Sending everything is expensive and can make the model less focused; sending too little causes it to guess.
Context engineering is the discipline of selecting and structuring the information the model needs for the task in front of it.
That may include a product requirements document, coding standards, framework documentation, examples, architectural decisions, task definitions, and acceptance checks. It also means recognizing when a conversation has become polluted by failed approaches or irrelevant history and starting again with a cleaner context.
This is one reason MCP is so promising. Instead of relying only on knowledge frozen at training time, an MCP server can give an agent access to updated documentation or a specific system such as GitHub or Figma.
The model still needs guidance, but it can consult a more reliable source rather than improvising around outdated APIs.
The Model Matters—but the Workflow Matters More
Different models vary in speed, cost, context capacity, and ability. Some perform better at code generation; others are useful as fast orchestrators that break work into subtasks. The most expensive or largest model is not automatically the correct choice for every step.
Benchmarks can help, but real project performance is more revealing.
A slower free model may reduce token costs while increasing human supervision and elapsed development time. A stronger model may solve a difficult problem in one pass and ultimately cost less.
The relevant metric is not simply the price of a token. It is the combined cost of model usage, developer attention, rework, and risk.
Watch Part 2: Building a Real Application With Agents
[
The second session applies these ideas in practice through a multiplayer quiz application built with agents, MCP tools, and multiple models.
The Experiment: An Agent-Built Multiplayer Quiz
For the practical session, the team built a simplified alternative to Kahoot: an organizer creates a room and a sequence of questions, players join, answers are submitted in real time, and the application displays results and a scoreboard.
The project had two parts. The backend used Express and WebSockets to distribute messages between the game master and players. The frontend used Next.js and a component library.
The team worked with an agent inside the development environment, several language models, Context7 for current documentation, and an MCP server provided by the UI library.
The experiment took roughly 20 hours of human work across two developers and consumed an estimated three million tokens. That total included the learning curve, the definition of rules and tasks, model comparisons, tests, and a full backend restart after the first result failed to meet the desired quality.
Almost none of the application code was written manually. But that did not mean the humans were absent from development. Their work moved up a level.
What Made the Agent More Effective
The most successful workflow began before code generation.
The team created separate product requirements documents for the backend and frontend, then translated each one into a granular task list. Every task contained a short objective, implementation steps, and checks the agent could run to verify its work.
The backend was completed and tested before frontend development began. Its WebSocket events were documented in Markdown, and that specification became part of the frontend context.
This created a stable contract between both sides of the application and reduced the chance that the agent would invent incompatible behavior.
Project rules also improved the results. Generic instructions such as “act as an expert frontend developer” were less useful than explicit principles covering architecture, TypeScript, reuse of existing libraries, Git workflow, and Conventional Commits.
When the agent repeatedly made the same mistake, the team did not merely correct the output. They refined the rules so the failure was less likely to recur.
Where Agents Still Struggle
Agents can sound confident while working from outdated documentation. They may combine incompatible dependency versions, recreate a utility that already exists in a library, abandon an earlier architectural constraint, or propose that the developer fix the problem when the task becomes difficult.
They also produce variable results. The same prompt and supporting files can lead to different implementation strategies.
That flexibility can be valuable, but it means a developer must define what matters in the specific case: readability, memory efficiency, speed, maintainability, or compatibility with an existing codebase.
Most importantly, agents still need close supervision.
In the experiment, the team had to watch how the agent interpreted tasks, stop unproductive paths, compare models, and evaluate code quality. Autonomy did not eliminate engineering judgment; it made that judgment the main control system.
A New Layer of Reusable Engineering Knowledge
One of the most promising outcomes is not the application itself, but the reusable system around it.
A well-designed set of rules, task formats, prompts, and verification checks can become organizational knowledge. Teams can extract general principles from a successful project, remove project-specific details, and reuse the result as a starting point for the next application.
That repository of agent-facing guidance may become as important as traditional boilerplates. It can encode how a company structures frontend work, reviews changes, writes tests, documents APIs, and makes architectural decisions.
It must remain concise and actively maintained: too many rules consume context, and stale rules can be as harmful as stale documentation.
The opportunity is not to create a giant prompt that replaces experience. It is to make engineering standards legible to both people and agents.
The Real Shift Is From Coding to Orchestration
Our sessions reinforced a simple conclusion: agents can generate a large amount of working software, but reliable outcomes depend on the structure around them.
Clear requirements, current documentation, bounded tasks, explicit constraints, automated tests, and human review matter more—not less—when code becomes easier to produce.
For development teams, the competitive advantage will not come from merely adopting the newest model. It will come from learning how to assign the right model, provide the right context, expose the right tools, and verify the result.
The developer’s role expands from implementing every detail to shaping the system that implements it.
At Zarego, these internal sessions are how we turn rapidly changing technology into practical knowledge. We test tools, document what fails, share what works, and use those lessons to build better processes for real projects.
AI agents are evolving quickly, but the direction is already clear: the future of software development will be collaborative, with humans defining intent and standards while agents help execute at a new scale.
