What is a background task in an agentic workflow? Take an agent like Muse, which is always thinking and ideating in the background. How would you build that? As far as I know, Meta hasn't published anything about how that process works.
My guess is that it's a prompt or some guidance paired with an ultra-cheap model, running one of the hotter buzzwords right now: loop engineering.
What loop engineering is
When you ask an LLM for an artifact, a resource or any other output, you get a first response, and its quality mostly reflects the quality of your prompt. Then you evaluate it. You're the one holding the true goal in your head, so you read the output, decide what's wrong and tell the model what to change. You're the loop.
Loop engineering moves that job out of your head. You architect a loop with a judge that reads the model's output and decides whether it meets the goal. For that to work, the judge has to be general: it takes your goal, your request and your requirements, and checks that all of them are met.
Take a résumé. You can ask Claude to write yours. It can pull in a bunch of information, put it in a clean format, even query your production analytics to drop real numbers into your bullets. But you still have to review it, find the problems and decide what to change. Maybe it featured a project that isn't relevant to the job you're applying for. The model did what you asked. It just didn't know why you asked.
Two loops, not one
If I were building this system, I'd split the request into two tasks:
- Build the résumé. This is simple and straightforward. We produce an artifact, and we can usually one-shot it. A few clarifying questions might get us a better result, but that's fine.
- Understand why the user wants it, and help them get there.
The first is the inner loop: generate the thing the user asked for, judge it, revise it. The second is the outer loop: a more general understanding of what the user is actually trying to get done. The résumé is a step. The goal is "I want to get a job."
Two loops
The inner loop builds what was asked for. The outer loop checks whether it moved the user toward why they asked.
I think that's the shape of an autonomous agent like Muse. Once you know the larger goal, you can periodically fire off a quick, cheap process that asks: have we achieved it yet? Should we check in? Should we suggest a few roles that fit the résumé we just worked on?
I'd go further and say most, if not all, autonomous agents can be built on this two-loop split. What will separate them is two things:
- When the agent jumps back in.
- How relevant the nudge is, and how easy it is to act on.
Timing is easy to get wrong in both directions. If we ask every couple of hours how the job search is going, the user gets annoyed and tells us to stop. If we check in once a month, they may have found a role before we did anything useful. If someone asks for help planning a party a week out and we don't follow up until the day before, they won't trust us to be reliable.
Relevance is the other half. If we misread the goal, or never asked a clarifying question, every check-in feels off, and the user decides we're either not very smart or just annoying.
Security
I'd be remiss not to mention security, at least briefly. An all-purpose autonomous agent raises real security concerns. Building one inside your own application is more manageable, because you control what it can reach. Once you let it execute broadly and give it access to external applications, like a bank account or other sensitive information, you have to design with a high level of security from the start.
Where does the goal live?
This makes me wonder whether there's room for a protocol, maybe an extension to MCP, that's responsible for holding that outer-loop context. Today's integrations mostly look like tools: Google Calendar, Gmail and Slack are things an agent does stuff with. But some apps exist because you're trying to reach a goal, like a fitness plan or a job search. Those apps already know a lot about where you are relative to that goal. If they could expose it, the agent's outer loop wouldn't have to reconstruct it from chat history.
That leads somewhere interesting: at what point does the context move off the agent entirely? We already talk about common memory formats so you can export from one agent to another. But what if the application owned the memory? The agent will always need some memory of its own. And memory as a service is effectively RAG. It's obviously not just RAG, though: memory needs some kind of hierarchical architecture of its own, and there are a lot of directions you could take in exploring what memory as a service would actually look like.
That's a deeper branch than I want to follow today. For now, we have an autonomous agent design to build on: an inner loop that makes the thing, and an outer loop that remembers why.