Context for Coding Agents

There is a lot of talk right now about AI making developers faster.

We agree with that, but speed is not the whole story.

In our day-to-day work, the slowest part of engineering is often not typing the code. It is building enough understanding to change the right thing without breaking something else.

That work is familiar to anyone who has spent time inside a large system.

Where does this live? Why does this service behave this way? Who owns this logic? Is this still used? Is the real behavior in this repo, or in the worker, or in the service it calls three steps later?

Those questions can burn an afternoon. They turn into Slack threads, calls, old pull requests, half-remembered decisions, and long walks through files hoping the next one is the right one.

From code generation to code understanding

When we started using Claude Code heavily, the part that changed our workflow was not only code generation. It was code understanding.

Being able to ask questions against a repository made exploration feel conversational. Instead of starting with a file tree and a guess, we could start with the question we actually had.

That sounds small, but when you do it every day, it changes the shape of the work.

We are Marcos and Frederico, longtime friends who have worked together across Streaming, Machine learning, AI Agents & Evals, all in very large codebases spread across many repositories. Between us, we have each spent more than a decade inside systems where the hardest problems were rarely isolated to one repository.

The real challenge was context: knowing the history, the boundaries, the conventions, the owners, and the path from a product question to the code that actually answers it.

The missing context

Claude Code made us excited about what coding agents could become. But it also made one limitation very clear: most real engineering systems do not fit neatly inside one repository.

They are spread across many repos, services, jobs, APIs, dashboards, queues, deployment paths, and operational assumptions.

A single agent looking at a single repo can help a lot, but it still misses the wider system that developers actually work inside.

That is why we started building Caramelo.

What Caramelo does

Caramelo is built around a simple idea: coding agents need better context before they can do their best work.

Caramelo connects repositories, absorbs the knowledge inside them, and helps agents retrieve the pieces that matter for the question in front of the developer.

In plain terms, it is a context orchestration layer for engineering systems: the part that knows where to look, how the pieces relate, and what context should be brought back before an agent tries to answer.

The goal is to remove the time we lose getting oriented, and making all the great coding agents we know tool even better.

Less digging through repos. Less guessing which service matters. Less time creating local hacks to give context from multiple repos to your agent. Less Time and Tokens.

Why Caramelo

The name is part of the story.

In Brazil, caramelo is not only a color. It is also the vira-lata caramelo: the caramel-colored mutt almost everyone recognizes. The dog outside the bakery. The dog crossing the street like it owns the neighborhood. The dog that shows up in memes, in adoption stories, and even in campaigns to put it on Brazilian money.

Not a breed exactly. More like a vibe.

Street-smart. Friendly. Resilient. The kind of dog that somehow belongs to nobody and everybody at the same time.

That felt right for what we are building.

What comes next

We are early, but the retrieval foundation is ready for real engineering work.

Now we want to battle-test it where the problem is most obvious: teams with many repositories, many moving parts, and too much important context living between them.

This blog will be our field notes. We will share what we are building, what we are learning, where agents still get lost, and how Caramelo changes as we put it in front of real multi-repo systems.

There is a lot more coming.