What DevDay Exchange showed about putting agents to work

Originally published on NewHack, on November 6, 2026.

In São Paulo, more than 500 attendees, case studies from QuintoAndar and iFood, and strategic people from OpenAI's global team gave scale to a conversation about how to create, coordinate, and evaluate work with AI.

On November 6, I attended the OpenAI DevDay Exchange in São Paulo. As a Codex Ambassador, I was among the 11 OpenAI ambassadors in Brazil who took part in the event. There were more than 500 people, including professionals from some of the country's largest companies, with a strong presence from OpenAI's global team.

The program combined technical sessions, demos, case studies from QuintoAndar and iFood, and conversations with the company's experts. São Paulo was one of eight cities in the international circuit, which brings developers and founders closer to the teams that build OpenAI's products.

For me, the thread that connected the presentations was how to organize work when agents can execute increasingly long tasks. What context do they need to receive? How should responsibilities be divided? Who verifies the delivery? And how do you track what happened when something turns out differently than expected?

These questions already matter to anyone leading product, engineering, or a business area. The more AI is able to do, the more important it becomes to decide what's worth delegating and how to recognize a good delivery.

The work continues after the first response

One of the sessions was titled “What comes after loops?” The conversation covered the structure that keeps an agent working throughout a task.

The model needs to receive context, choose tools, examine results, and decide how to continue. Along this path, it produces files, discovers constraints, and makes decisions. This set of mechanisms is usually called a harness.

Imagine an investigation into a product failure. The agent checks logs, finds a hypothesis, reads the code, and runs a test. The result may rule out the first hypothesis and require another path. To continue, it needs to preserve what it has already learned and remember which problem it was trying to solve.

A presentation can show the final result of this process. In operation, what matters is being able to walk the path, handle a blocker, and verify whether the goal was achieved.

The session “Harness-as-a-Service with the Agents API” was also on the program. The API's proposal, announced by OpenAI before the event, is to offer this managed execution layer. For builders, this makes it possible to focus more effort on the data, tools, and workflows specific to the customer.

My reading is that an AI startup's differentiation will increasingly depend on knowing this work in detail. Two companies can use the same model and deliver very different results because one of them better understands the exceptions, the information sources, and the customer's completion criteria.

A prompt can also organize a team

One of the slides that caught my attention the most showed instructions for dividing work among subagents. The guidance was to open independent workstreams, define outcomes and responsibilities, communicate dependencies, and integrate the delivery at the end.

This kind of instruction reveals a shift in how we work with AI. When there are several workstreams in parallel, someone needs to say how they come together.

Think of an application with one person handling the interface, another the integration, and another the tests. If the integration changes the data format and that decision doesn't reach whoever is building the interface, the parts can all be finished and still fail together. With agents, the dependency still exists.

Another slide dealt with keeping a record of the goal, the instructions, the people responsible, the pending items, and the decisions. In long tasks, this record helps resume work without losing the conditions that guided the first choices.

This connects with something I've been advocating in our AI activities at NewHack. Before jumping straight into asking for implementation, it's worth making explicit what we want to build. When execution speeds up, an ambiguous specification can generate more rework in less time.

The practical consequence is paying attention to the beginning and the end of the task. At the start, define the outcome and the constraints. At the end, verify whether the solution meets what was agreed. Between these two points, the agent can gain room to investigate and propose paths.

The next application can start in a spreadsheet

In the session on Sites and the next generation of web applications, a demo started from a spreadsheet to create a release-tracking application. The request included an existing visual system, milestones, filters, and different ways to view the work.

This is an example close to many companies. A spreadsheet holds the information, but the team needs a better experience to consult, track, and act on it. The ability to build that application with AI reduces the effort needed to test whether it solves the problem.

The discussion also touched on applications prepared to interact with agents. Some users may arrive at a service accompanied by an AI that looks up information and performs actions on their behalf.

For founders, this expands the product questions. Beyond thinking about how a person finds a feature on the screen, it now matters how that feature is presented to an agent, which actions it allows, and how it confirms the result. The experience needs to remain understandable and controllable throughout this path.

Security enters into the way you delegate

The program set aside a session for “Codex Security: from vulnerability to verified fix.” In the panel with experts, a question brought the topic into companies' daily routine. What controls should be adopted before allowing an agent to access internal systems or change code?

One example discussed was access to a ticketing system. If the task only requires looking up tickets, the credential can be limited to read access. The discussion included testing behavior in a controlled environment, monitoring execution, and defining when a person needs to approve the action.

The value of this approach shows up when something goes wrong. The team needs to be able to reconstruct what information the agent received, which tools it used, and where it made a decision that deserves review.

The panel also brought up the hub-and-spoke model. A technical core establishes standards and guides the architecture, while people from different areas help identify uses and spread knowledge.

I see sense in this proposal because the best problems to solve are scattered across the company. The support team knows the customer's exceptions. Finance knows where the closing process gets stuck. Engineering understands the systems' dependencies. Creating a way for these people to experiment with technical support can turn curiosity into projects the organization can actually track.

The Brazilian case studies bring the discussion close to home

Having QuintoAndar and iFood in the customer block brought a Brazilian reference to the event. These are companies that run complex journeys, with decisions, integrations, and people spread across several stages.

For those in the audience, this helps formulate questions about their own business. Where does information get lost between two areas? Which task takes up hours of someone who deeply understands the process? What can be tested without compromising operations?

The presence of strategic people from OpenAI's global team also creates an opportunity to bring these difficulties to the people who build the tools. The experience of putting AI to work in Brazil has its own conditions, its own existing systems, and its own users. This feedback is part of the exchange that gives the event its name.

What I would take to the next project

In the warmup we did with Marcelo Okano at NewHack, the conversation already touched on what changes when implementation gets faster. DevDay Exchange gave us more material for this discussion.

I would start by choosing a recurring piece of work, with someone responsible who can say what a good delivery means. I would record the goal, the sources, and the decisions that need to remain available. Then I would give the agent the tools and access needed to test that flow.

I would measure the result including the review effort and the handling of exceptions. It's this evidence that lets you decide whether it's worth expanding autonomy, changing the design, or trying another case.

I left the event with more interest in this work of construction. Choosing the problem, specifying, experimenting, verifying, and sharing what we learned. Agent capability is advancing fast. Knowing how to organize this work is a skill we can already develop.