More than a presentation about tools, the session brought an important reflection on how
developers need to learn how to work with AI in a structured way. It is not enough to ask
a tool to generate code. It is necessary to understand context, boundaries, permissions,
memory, responsibilities, and workflow.

As part of the SouJava JUG, SouJava Brasília continues to create spaces
where the community can discuss current topics, experiment with new approaches, and understand
how artificial intelligence is transforming software development in practice.

Agents as digital collaborators

One of the central points of the presentation was the comparison between agents and digital
collaborators. Rodrigo explained that an agent can be seen as an employee or an intern:
someone who needs clear instructions on how to act, which tasks to execute, which limits
to respect, and which tools can be used.

This comparison helps explain why many experiences with AI fail. When an agent receives a
vague instruction, insufficient context, or poorly defined permissions, the result tends to
be inconsistent. The problem is often not only in the model, but in the way the work was
structured.

That is why building good agents requires more than large prompts. It requires role clarity,
objective definition, context management, tool specification, and constant validation of what
is being produced.

Model, memory, tools, and output

To explain the structure of an agent, Rodrigo introduced some fundamental elements:
model, memory, tools, and
output.

The model defines which LLM will be used to execute a task. Memory represents how the agent
maintains or retrieves context throughout the interaction. Tools indicate which actions the
agent can execute, such as reading files, writing code, searching information, modifying files,
or interacting with external systems. The output is the expected final result.

This structure seems simple, but it changes the way we think about development with AI. Instead
of treating AI as a generic text box, we start seeing it as part of a work architecture, with
inputs, processing, tools, and expected outcomes.

Working well with agents is not only about asking for better answers. It is about designing
better context, better boundaries, and a better execution flow.

The hallucination problem and the importance of context

One of the challenges highlighted during the session was model hallucination. Rodrigo explained
that many errors happen when the agent loses part of the context, misinterprets an instruction,
or does not have clear boundaries about what it should or should not do.

This point is especially important in software development scenarios. An agent can generate a
solution that looks functional, but is outside the company’s guidelines, misaligned with the
architecture, insecure, or unnecessarily complex.

That is why context management becomes a central skill. The developer needs to know how to provide
relevant information, reduce ambiguity, organize instructions, point to documentation, define
responsibilities, and critically review the result.

AI can accelerate work significantly, but it still needs technical direction. Without that direction,
speed can simply produce problems faster.

The structure of a subagent

The most practical part of the session began with an explanation of the structure of a subagent.
Rodrigo showed that these agents can be defined in Markdown files, with a header containing
information such as name, description, available tools, model, permissions, skills, and hooks.

The name identifies the agent. The description explains when
it should be used. The tools define what it can access. The model
determines which LLM will be used. The permission mode defines the level of
permission to execute actions. Skills represent specific capabilities. And
hooks allow actions to be executed at specific moments in the flow.

This kind of structure is important because it turns agents into reusable components. Instead of
creating a loose instruction every time, the developer starts to have specialized agents, with
well-defined responsibilities, capable of acting in different stages of the development workflow.

The power of “is, is not, does, and does not”

One of the most interesting parts of the session was the way Rodrigo defined boundaries for an
agent. He brought the idea of structuring an agent around four questions: what it is, what it is
not, what it does, and what it does not do.

This approach helps reduce ambiguity. When we only say what the agent should do, we still leave
many gaps for undesired interpretations. But when we also make clear what it should not do, the
boundaries become stronger.

Rodrigo reinforced that, in many cases, the “no” educates the agent better than the “yes”. In other
words, the clearer the limits, the lower the chance that the agent will act outside the expected scope.

This idea is extremely valuable for corporate environments, where following standards, policies,
architecture, and business rules is just as important as delivering quickly.

Skills: capabilities to save context and improve execution

Another central topic was the use of skills. Rodrigo explained that skills are
capabilities that can be reused by agents to execute specific tasks more efficiently.

The biggest advantage of skills is context management and resource savings. Not every task needs
to call an LLM. In some cases, commands, scripts, or well-defined instructions can solve part of
the work with more speed, lower cost, and less token consumption.

For example, if an agent needs to analyze the diff of a pull request, locate files, generate a
summary, or apply a specific convention, a skill can provide that behavior in a specialized way,
reducing the need to repeat large blocks of instruction.

This makes the workflow more organized, cheaper, and more predictable. In real projects, that
difference matters.

Hooks and permissions: control over the flow

In addition to skills, Rodrigo also introduced the idea of hooks, which work as
triggers executed at specific moments of an agent’s flow.

A hook can be used, for example, at the end of a code review, to generate a commit message, prepare
a change, execute an additional step, or trigger an automated process.

This kind of mechanism shows that working with agents is not just about chatting with AI. It is
about designing development flows where tasks can be chained, automated, reviewed, and integrated
with practices that already exist within the team.

Permissions also play an important role. An agent should not have unrestricted access to everything.
As in any system, it is necessary to control what can be read, edited, executed, or blocked.

A software factory with specialized agents

One of the strongest moments of the presentation was the idea of organizing agents like a small
software factory. Instead of having a single agent trying to do everything, Rodrigo proposed a
workflow with agents specialized in different roles.

A business strategy agent can analyze requirements, understand objectives, identify gaps, and
generate questions. A UX agent can transform those requirements into an experience proposal.
Another agent can handle visual details, animations, and usability. A frontend agent can implement
the interface. A QA agent can review and test the result.

This chaining creates an agent pipeline, where the output of one becomes the input for the next.
The logic is similar to the workflow of a real development team, with different roles collaborating
to deliver a better solution.

The main difference is that, with well-defined agents, part of this process can be accelerated,
tested, and repeated much faster.

Developers remain essential

Despite all the potential of agents, the session delivered a very clear message: developers remain
essential.

Rodrigo reinforced that AI changes the way we work, but it does not remove the need for technical
knowledge. On the contrary. The more tools generate code, the more important it becomes to know
how to evaluate whether that code is good, secure, scalable, observable, and aligned with proper
practices.

People without software development knowledge may be able to create prototypes using AI, but when
the system needs to become a real product, someone will need to think about architecture, API
contracts, security, observability, quality, deployment, maintenance, and evolution.

This reinforces an important vision for the community: this is not the time to stop studying.
It is the time to study even more, but with a new mindset.

From idea to prototype in minutes

To demonstrate the concepts in practice, Rodrigo built a prototype of a meeting agenda generator.
The idea was to create a simple application, with HTML and CSS screens, capable of capturing
information such as the meeting topic, main objectives, estimated duration, and number of participants.

Based on this information, the prototype simulated AI action and generated a structured agenda for
the meeting. The goal was not to create a complete final product, but to show how specialized
agents can accelerate the prototyping stage and transform an idea into something navigable quickly.

During the demonstration, the agents searched for components, organized the flow, created files,
defined screens, and delivered a functional prototype in just a few minutes.

This example showed in a concrete way how a chain of agents can be used to reduce the time between
an initial idea and a first version that can be validated.

Productivity with responsibility

The promise of productivity with agents is huge. Rodrigo mentioned that tasks that could previously
take days or weeks can be accelerated to minutes when the flow is well designed.

But the session also made it clear that speed without criteria can be dangerous. Good agents need
good context, clear limits, good examples, well-defined permissions, and proper human review.

Real productivity does not come only from generating code quickly. It comes from generating something
useful, aligned, reviewable, secure, and capable of evolving.

This is a fundamental difference. AI can accelerate delivery, but engineering remains responsible
for turning speed into quality.

Final thoughts

SouJava Sessions #003 brought a practical and thought-provoking view of the future of software
development with agents and subagents.

Rodrigo Fernandes’ talk showed that the new phase of AI in development will not be only about
asking a tool to generate code. It will be about designing workflows, creating specialized agents,
controlling context, defining boundaries, reusing skills, automating steps, and keeping the developer
at the center of technical decision-making.

For the Java community, this discussion is especially important. Java has always been connected to
corporate systems, architecture, quality, and long-term maintenance. Now, with AI, agents, and new
forms of productivity, this knowledge becomes even more valuable.

The final message is simple: the way we work is changing, but technical knowledge remains what
separates fragile prototypes from real products.

SouJava Brasília continues as a living movement: where knowledge, technology, and community
come together to shape better professionals and build more relevant solutions.