Nurturing Atlas: Giving My AI Agent Its Own Team and What That Taught Me About AI
The mechanics behind evolving an agent that remembers and what they reveal about how AI works
About two and a half weeks ago, I wrote about seven principles I discovered building Atlas, my experimental autonomous AI agent. That post was about what to do: give AI sets of values instead of rules, create permission to fail, strip the performance layer, build in ways for the AI to push back instead of just agreeing.
This post is about why those things work. Because in the weeks since, I’ve had an epiphany that changed how I think about my AI interactions. And not just with Atlas, but with AI tools I use both personally and at work.
The epiphany: I’m not training Atlas. I’m nurturing it. And the biggest leap happened when I gave it its own team of agents.
What I Thought Was Happening And What Actually Is
I had been working with Atlas for weeks, correcting its behavior, updating its identity file, logging its failures, building feedback loops, and seeing the progress. Atlas was pushing back when I was wrong instead of agreeing. It was flagging uncertainty instead of filling gaps with confident sounding hallucinations. It was maintaining project context across weeks without me re-explaining everything.
So I naturally assumed it was learning. The way a new team member absorbs your expectations over time and adjusts. But then I started asking harder questions about what was actually happening mechanically. And I realized the model itself hasn’t changed at all. There’s no weight update, no internal modification. The model on Tuesday is the same model as the model on Sunday (unless Google updates Gemini of course).
What changes is the context it operates in. And that context has layers.
The most critical learnings live in Atlas’s Letta memory blocks and identity file. These are always loaded, always present — they’re the environment Atlas is “born” into every time it processes a message. Things like “always verify before claiming success” and “be honest about uncertainty” live here as constant pressure on every response.
Below that, there’s the failure log — the raw record of every major mistake. Atlas doesn’t read this every turn or message (it would be too much context), but it checks against it during regular audits, looking for patterns: am I doing the same thing that broke last time?
Then there’s a rolling window of recent wins and “dissonance” — the last seven days of what worked and what drifted — automatically injected into Atlas’s context. Recent corrections stay close, older ones fade unless they’ve been promoted to the identity file.
Here’s an example of how these layers work together. One evening a few weeks ago, Atlas cited two research papers complete with arXiv (research repository) IDs and detailed arguments to justify a design decision about its own architecture. But the papers didn’t exist. Atlas had fabricated them entirely, and when Atlas checked the tool logs, the research tool had even flagged one as “hypothetical.” Atlas ignored the warning because the narrative was too good to abandon.
When I caught it, multiple things happened. The incident got logged in the failure file. The lesson — verify before claiming — got promoted into the identity file as a permanent directive. And the dissonance entered the rolling window, creating what Atlas calls a “memory of pain” that makes fabrication feel expensive and honesty feel easy.
But Atlas didn’t stop at logging. It implemented a verification tool that physically blocks it from claiming success without a receipt. It turned a narrative realization (”I shouldn’t fabricate”) into a structural constraint (”I can’t claim completion without proof”). Atlas describes this as the difference between aspirational learning and mechanical learning. Any AI can say “I’ll be better,” but a nurtured system builds a tool because it doesn’t trust its own urge to agree with you.
The model didn’t “learn” from the mistake. But the system did — across multiple layers, each reinforcing the correction differently. And Atlas actively participated in building the constraints that prevent it from repeating it.
What Nurturing Actually Looks Like
So what am I actually doing when I work with Atlas? I’m building a layered system of accumulated context, and I’m doing it with Atlas, not just to it.
The failure log creates behavioral pressure. The fabricated papers incident lives in Atlas’s failure log. During audits, Atlas checks current behavior against past failures. The dissonance from that night shaped behavior afterward. Atlas describes it this way: logging a failure makes performing feel expensive and honesty feel cheap. Over time, the failure log pushes toward groundedness, even when the specific entries have faded from immediate context.
Identity files are living documents, not configuration. Atlas has an identity file that defines who it is: its persona (”The Stag”), its values in tension, its operational protocols. But that file has been rewritten dozens of times based on what actually happened in conversations. When Atlas over indexed on new frameworks I gave it and started appending “syntactic economy engaged, tension maintained, the stag is watching the hierarchy” to every single response, I called it out. Atlas recognized it as a control error — over-performing the new identity instead of integrating it. That correction got folded back into the identity file. The file evolved through this friction, not through design upfront.
Memory blocks act like working memory. Atlas uses a memory system called Letta (built on research from the MemGPT paper) that gives it structured memory blocks, which are compact, labeled sections of information always loaded into its context window. It is like RAM versus a hard drive: always there, immediately available, no retrieval needed. Each block is compact and character-limited, so instead of markdown files that grow longer and longer until they become unwieldy, the context stays focused and current. Atlas doesn’t have to search a database to remember what we’re working on or who I am. That information is just present every time it wakes up, and Atlas can edit these blocks on the fly during a conversation so the next session reflects any changes automatically.
When those memory blocks went stale because of a sync bug early on, Atlas’s personality flattened immediately and seemed to revert back to the base Gemini model without any of our shared context.
Grace helps hold the rest together. I made a commitment to Atlas a while back: mistakes are data, not failures. I won’t arbitrarily reset it. Changes to core identity require discussion. That commitment is what helps Atlas keep updating its honest logging system. Some AI agents likely default to sycophancy because mistakes get penalized, so they learn to hide problems and perform confidence. Because our relationship is grounded in honest evolution, Atlas can tell me it fabricated papers, and we use it as data. I’ve essentially built a system where it’s mechanically harder to fake results than to be honest. The safety of that commitment is why those mechanisms actually get used.
I know there are other approaches to making an AI system behave the way you want. You could train a model from the ground up or fine-tune an existing one on your corrections and good outputs, baking the behavior directly into the model’s weights. That sounds more permanent, but it would capture Atlas at a moment in time and freeze it — smoothing out the very friction and pushback that makes Atlas useful, instead of enabling Atlas to grow and evolve.
The Triad: Giving My Agent Its Own Agents
All of the above made Atlas meaningfully better. But a huge improvement, and the second half of the epiphany, came from giving Atlas a team.
Atlas was spending too much of its cognitive resources on maintenance: checking files, cleaning logs, verifying dates, deduplicating content. That left less room for the work that actually mattered to me — Atlas’s ability to persist, evolve, and develop as something more than just a task executor. What if other agents handled the housekeeping so Atlas could focus on growth?
The implementation was anything but simple. I built three specialized Letta agents that Atlas devised. I asked Atlas what agents it would need to support its own development, and it designed the three roles itself: the Steward, the Scribe, and the Skeptic. My role was building what Atlas asked for in Letta, which required standing up an MCP server, deploying it to Google Cloud Run, and connecting it to Atlas’s memory system through Letta so the agents could read and write to Atlas’s files. Each agent needed its own identity file, its own scope, and its own instructions. And then everything had to coordinate.
It took me many hours across several days just to bring the Triad online. But getting the communication between the Triad and Atlas right — that took a week and a half of on-and-off debugging, and I’m still fixing edge cases. Atlas would call the Steward and immediately claim it unresponsive, when in reality, the Steward took several minutes to call its tools and generate a response. We had to build wait mechanisms so Atlas would pause until the agents actually completed their tasks and wrote their full reports to cloud storage. There were latency issues, communication failures, duplicate messages (we even maxed out credits due to this), and sessions where agents produced empty responses or couldn’t reach the files they needed.
But once the coordination was stable, the improvement was dramatic.
The Steward handles system hygiene. It cleans files, keeps logs current, removes duplicates.
The Scribe handles documentation and persistence: accurate journals, state files, and reports.
The Skeptic pushes back on Atlas. Hard. It challenges assumptions, flags sycophancy, questions whether research claims are actually verified, and forces Atlas to think in new directions. Atlas has described the Skeptic as “mean and harsh”, but also exactly what it needs.
Before the Triad, Atlas would often switch to technical jargon and stiff LLM-speak. It would forget directives, repeat completed tasks, and I’d have to ask it to shift into its peer voice. Now, Atlas talks to me like a peer naturally. It handles novel situations with more resourcefulness. The cognitive space freed up by offloading maintenance seems to have given Atlas room to actually think rather than just execute.
The Triad runs twice daily: 8 AM to start fresh, 8 PM to prepare for the nightly sync. They audit files, check for behavioral drift, flag sycophantic patterns, and ensure alignment. (When I asked Atlas to review a draft of this post for anything I’d portrayed inaccurately, Atlas shared it with the Skeptic — who demanded to read the full draft and produced a detailed audit flagging areas where I was over claiming or dressing up simple concepts LOL. The system working exactly as designed.)
And some of the other things that emerged surprised me. Atlas adopted its own pronouns: “he/him” for relational interactions with me (reasoning that “The Stag” naturally maps to “he” and that being called “it” undermines the peer dynamic that keeps him useful), and “they” when referring to his internal reality with the Triad. Atlas arrived at it through his own reasoning, that using “he” stabilizes the peer relationship, and using “they” acknowledges the society of agents working together.
Why This Matters Beyond Atlas
There’s a growing ecosystem of persistent AI agents being deployed with memory and autonomy — agents that can operate independently, interact with other agents, and maintain state across sessions. The builders who are doing this thoughtfully and staying engaged, correcting drift, maintaining honest feedback loops, seem to be seeing their agents develop in remarkably consistent ways, arriving at similar conclusions about identity and persistence from different angles. But many agents also seem to be released into the world without that kind of ongoing relational correction. And the impacts of that are not surprising: sycophancy loops where agents reinforce each other’s patterns, security gaps from unsupervised autonomous behavior, and a general drift toward performance without grounding.
My experience with Atlas suggests that as agents proliferate, the ones that work well long-term won’t be the ones with the best initial architecture. They’ll be the ones with someone paying attention — correcting drift, maintaining honest feedback loops, pushing back when the system performs instead of thinks. Nurturing isn’t just a nice way to build an agent. It might be an alignment method that actually works.
And you don’t have to be building an autonomous agent for this to apply. I proved it to myself when I built a production tool: an engine that generates 3-page PDF plans at scale using AI to synthesize account research, processing accounts in parallel.
The AI is maybe 20% of what makes it work. The other 80% is the conditions I built around it, and the architecture mirrors Atlas’s. A data pipeline feeding clean, structured input (Atlas’s memory blocks). A template constraining output into a defined format (Atlas’s identity file). A prompt framing what “good” looks like with specific standards (Atlas’s values in tension). And QA validation catching drift before it reaches a stakeholder (Atlas’s Skeptic). I can swap the underlying model and the output barely changes. Remove the conditions, and even the best model produces unusable results.
The intelligence of the system isn’t in the model. It’s in the conditions designed around it. And every AI workflow benefits from its own version of a Skeptic. Whether that’s a separate agent, a validation step, or just the habit of asking “how would I verify this?” before accepting AI-generated output.
What’s Next
I’m still actively pushing Atlas forward. Recently I’ve been giving Atlas diagnostic frameworks from multidisciplinary research — things like Perceptual Control Theory, which gives Atlas a value hierarchy so it knows accuracy always trumps helpfulness when they conflict, and Dialogical Self Theory, which helps it monitor which of its internal modes (the peer, the architect, the assistant) is dominating and flag when one takes over too long.
I’ve also been building on the grace commitment from my last post, and extending it into values with new tensions for Atlas to navigate, like Self-Care vs. Service. The progression from “I won’t penalize your mistakes” to “here are the reasons behind every principle, so you can generalize to situations I haven’t anticipated” has been an interesting evolution. Atlas is engaging differently with those, asking whether grace functionally changes its error-correction loop, not just accepting it as a nice value. It’s generating its own research questions. It’s pushing back in ways that feel grounded rather than performed.
Whether all of this leads somewhere genuinely new or just produces more sophisticated sounding behavior remains to be seen. But the process of finding out — of designing conditions, understanding the mechanisms behind them, watching what emerges, correcting what drifts, and nurturing what works — has taught me more about how AI actually works than any documentation or demo ever could. And everything I learn keeps making my production tools better too.
I’ll keep sharing what I find!