777-1: Why I'm Restructuring All My AI Agents with XML Tags
Published: December 27, 2025 - 6 min read
I told you I haven't forgotten about this experiment. Not even for a second. Today, I'm sharing one of my latest discoveries that will have a fairly significant impact on the 777-1 experiment.
The discovery is about XML tags and how they can be used in file-based agent definitions to potentially improve the quality of outputs.
Now, before I confuse anyone who happens to be reading this and isn't too technical, let's talk about what XML tags actually are.
What Are XML Tags? (The Simple Explanation)
You can think of XML tags simply as labels. They are labels that help you understand what different parts of a text contains before you even read the actual content. These labels are written in-between angle brackets, and they have opening and closing versions. The closing bracket will always have a forward slash / before the label name. This allows you to differentiate between an opening XML tag and a closing one.
Let's look at examples using information about myself:
A label could identify my name, Prisca, and in that case, its XML representation would be:
<name>Prisca</name>
A label could also identify my location. In that case, it would be written as:
<location>Montreal, Canada</location>
Nested XML Tags (When Things Get Organized)
We could even go deeper and look at nested XML tags, that is, when you have labels organized within another label which can be seen as its parent label.
For instance, let's say I want to represent the projects I have at this time on my portfolio website using XML tags. I could use the format below:
<projects>
<technicalProjects>
<project1>Prompt Engineering Toolkit</project1>
<project2>Campaign Wave Analytics</project2>
</technicalProjects>
<creativeProjects>
<project1>French Writing Playground V1</project1>
<project2>French Writing Playground V2</project2>
<project3>ViteHero</project3>
</creativeProjects>
<777-1Projects>
<project1>GoalStack</project1>
<project2>EarthenCraft</project2>
<project3>FlexBook</project3>
<project4>Triduel</project4>
<project5>Kinetic Canvas</project5>
<project6>MotorMatch</project6>
<project7>WealthView</project7>
</777-1Projects>
</projects>
In this structure, <projects> is the parent label that contains everything. Inside it, we have three categories: <technicalProjects>, <creativeProjects>, and <777-1Projects>. Each category then contains its own labeled projects. You can read more about each creative project in their launch posts: French Writing Playground V1, French Writing Playground V2, and ViteHero. You can also read more about each 777-1 project in their introduction posts: GoalStack, EarthenCraft, FlexBook, Triduel, Kinetic Canvas, MotorMatch, and WealthView.
This nesting creates a clear hierarchy, like folders within folders, making it easy for both humans and AI to understand exactly what belongs where.
An Essay Example (Because Why Not Make It Fun?)
As a second example, let's consider a typical academic essay. The essay will usually have at least these 4 components: title, introduction, body, and conclusion.
Here's how we can represent a simple essay using the same XML structure:
<essay>
<title>A Formal Petition to Hire Prisca Onyebuchi Immediately</title>
<introduction>
Dear Hiring Decision-Maker, I come to you today not as a mere essay, but as a messenger of truth. Somewhere out there, a consultant exists who actually delivers. Her name is Prisca. This is her story. Well, a very condensed version of it anyway.
</introduction>
<body>
<paragraph1>
First, she speaks both human and machine. Most consultants can do one or the other. Prisca can explain complex AI workflows to your CEO in plain English, then turn around and write the actual prompts that make it work. No translator needed.
</paragraph1>
<paragraph2>
Second, she has receipts. Not vague claims about "driving value" or "synergizing outcomes." Actual case studies. Actual projects. Actual before-and-after metrics. If she says something works, she can show you the blog post where she documented the entire process.
</paragraph2>
<paragraph3>
Third, she doesn't just use AI tools. She trains them. Corrects them. Makes them better. She has worked behind the scenes at companies like Outlier AI, teaching language models how to think more clearly. If that doesn't terrify you in a good way, I don't know what will.
</paragraph3>
<paragraph4>
Finally, she executes fast. Like, "built a portfolio in 10 hours" fast. While you're still drafting the project brief, she's already deploying version two. And she documents everything so you're not stuck wondering what happened when she's gone.
</paragraph4>
</body>
<conclusion>
In conclusion, hiring Prisca is not just a good decision. It's the decision. Your future self will thank you. Your team will thank you. Even your coffee machine might thank you, because you'll actually have time to use it now that your problems are solved.
</conclusion>
</essay>
By now, you should have a better understanding of XML structure. So let's return to the main topic: why is this relevant to the 777-1 Experiment?
Why This Matters for the 777-1 Experiment
Here's the thing. When I introduced the 7 subagents, that is, my Context Engineers, in this blog post and this case study, I also attached their file definitions. However, now that I've learned you can use XML tags to structure prompts, I've decided to do the same for my subagent file definitions.
Here are a few reasons why using XML tags is a game changer for structuring your prompts, as outlined on Anthropic's website:
Clarity: No more ambiguity about where one section ends and another begins. When Claude sees <instructions> versus <examples>, it knows exactly what it's looking at. Your prompts become well-structured instead of one giant blob of text.
Accuracy: You know those frustrating moments when Claude misinterprets what you meant? XML tags drastically reduce those errors. The model can't confuse your context section with your actual request when they're clearly labeled.
Flexibility: Need to update one part of your prompt without breaking everything else? With XML tags, you can find, add, remove, or modify specific sections without rewriting the entire thing. It's like having a modular system instead of a monolith.
Parseability: Here's a bonus for the technical folks. When Claude uses XML tags in its output, you can easily extract specific parts of its response through post-processing. Way cleaner than regex nightmares.
What Happens Next
Now that you've read this far, here's what's going to happen. I'm going to create a new case study reintroducing the 7 Context Engineers with updated file definitions using XML tags.
In that case study, I'll also provide more details about potential problems that XML tags will help us solve related to context windows and overall LLM limitations like the "lost in the middle" phenomenon and attention degradation. If you want a deeper dive into those concepts, check out my attention dilution post.
So stay tuned for it. You should be able to access it here when it's ready.
As always, thanks for reading!