777-1: The Workflow That Would Have Been a Disaster

777-1: The Workflow That Would Have Been a Disaster

Published: December 9, 2025 • 12 min read

When I wrote my first blog post about tokens, I promised you that all my posts about tokens were important to the 777-1 Experiment. In this blog post, I'm going to explain why.

Now if you have no clue what the 777-1 experiment is, I suggest you read this blog post first and maybe this one right after to meet Amber Williams, Kristy Rodriguez, Micaela Santos, Lindsay Stewart, Eesha Desai, Daniella Anderson, and Cassandra Hayes, my team of 7 subagents.

Now on to the main point of this blog post. Learning about tokens, context windows, the lost in the middle phenomenon, etc. has done two things for me:

1. It exposed my previous bad practices when working with AI.
2. It changed the path I have now chosen to follow for this experiment.

Let me explain further.

The Original Plan (That Would Have Crashed and Burned)

So I have an application that you all have never seen. It's a test site that acts as a sandbox application for me to use for experiments. The test site is where I break and rebuild things without affecting my portfolio projects. It's especially useful when preparing a blog post about a Claude God tip.

After creating my 7 subagents, I started a Claude session in my terminal and ran all of the subagents through that site within that session just to see how they run together.

My original plan for the workflow was to create a slash command that ran a script which called all the subagents sequentially after Claude's general purpose subagent ran to build the core of the application, and then tried to fix whatever issues were left for each app and use that as the core of the algorithm.

Now hopefully if you're reading this, you've also read all my blog posts about tokens. If not, you can read this post where I summarize some of the main points. The point is, if you've read those posts, you should immediately see why this is an issue.

The Math: 8,400 Tokens Before Any Work Happens

For the first issue, let's do some math. In the case study for the 777-1 experiment, I provided access to all the subagent files.

If you look at them, you will see that each one is quite long. When I call any of my subagents, their entire markdown specification gets loaded into the context window of that Claude session.

Let's assume that each of these subagents use up approximately 1200 tokens. If I load them all in the order I described in this blog post with Amber Williams, the Mobile-First Perfectionist being called first and ending with Cassandra Hayes, The Feature Detective, this is what the token load would look like for a single project:

That's ~8,400 tokens consumed just in loading the subagent specifications before any actual work happens.

If I call all 7 of them in a single session, you can imagine how quickly the context window would fill up. By the time Cassandra Hayes starts working, she would be operating in a context window that is nearly full or one that has already been compacted automatically.

The Double Whammy: Attention Dilution + Lost in the Middle

Then there is the phenomenon of attention dilution as well as that of "lost in the middle" that also come into play. In this blog post, I talked about these 2 phenomena distinctively, but what happens when we consider the compounding effect that they have if I choose to run all my subagents through a single codebase in the same Claude session?

First, a brief reminder of the differences between them:

• Attention dilution is about QUANTITY. As you increase the amount of tokens within a context window, the total attention capacity gets spread thinner across everything.
• "Lost in the middle" is about POSITION. Regardless of the size of the tokens used up in a context window, content at the beginning and end receives stronger attention than content in the middle.

When these two phenomena come into play for this experiment, Micaela Santos, Lindsay Stewart, and Eesha Desai's work are at the highest risk in terms of quality because of their position in the sequence with which I plan to call all the subagents.

Here is a diagram to quickly demonstrate why that is the case:

SUBAGENT ATTENTION ANALYSIS (Single Conversation)

Position in Context:
+-- System Prompt -------------------- [BEGINNING - Strong position]
+-- Project Instructions ------------- [BEGINNING - Strong position]
+-- Amber's work (Subagent 1) -------- [EARLY - Good position, minimal dilution]
+-- Kristy's work (Subagent 2) ------- [EARLY-MID - Weakening position]
+-- Micaela's work (Subagent 3) ------ [MIDDLE - Weak position + dilution]
+-- Lindsay's work (Subagent 4) ------ [MIDDLE - WEAKEST ZONE]
+-- Eesha's work (Subagent 5) -------- [MIDDLE - Weak position + dilution]
+-- Daniella's work (Subagent 6) ----- [LATE-MID - Recovering position]
+-- Current conversation ------------- [END - Strong position]
+-- Cassandra's analysis ------------- [END - Strong position]

You will notice from the diagram above that Amber Williams' work, while old and diluted, still benefits from being near the beginning. The "lost in the middle" phenomenon gives her work some protection because it's part of the early content in the context window.

However, Micaela Santos, Lindsay Stewart, and Eesha Desai (that is subagents 3, 4, and 5) are in the true middle which causes them to get hit by BOTH phenomena simultaneously:

• Position penalty (middle of context)
• Dilution penalty (context is very full by then)

What Cassandra Might Remember (and Forget)

By the time Cassandra Hayes (The Feature Detective) does her holistic review to check, "Do all features work together?", she might remember:

• The initial project structure which was defined in the beginning
• Daniella Anderson's recent TypeScript fixes

Here is a visual illustration of how Cassandra's attention to all other subagents' work might look like:

Attention Strength by Subagent (when Cassandra reviews):

Subagent 1 (Amber):     ████████░░░░ (65%) - Good position, but diluted
Subagent 2 (Kristy):    ██████░░░░░░ (50%) - Position weakening + dilution
Subagent 3 (Micaela):   ████░░░░░░░░ (35%) - Middle zone starting
Subagent 4 (Lindsay):   ███░░░░░░░░░ (25%) - WORST: True middle + full dilution
Subagent 5 (Eesha):     ████░░░░░░░░ (35%) - Still in danger zone
Subagent 6 (Daniella):  ███████░░░░░ (60%) - Recovering (recency helping)
Cassandra's own work:   ██████████░░ (85%) - End position advantage

Note that the percentage values above are conceptual illustrations, not precise measurements. However, let's now look at two concrete examples of how Cassandra might break things in this workflow as a result of these two phenomena.

Example 1: The Dark Mode Disaster

Let's say I am building an app and I run all these subagents through it. By the time I call Micaela Santos, The Design System Guardian, she notices that the application needs a theme toggle so she runs through the app and adds a dark mode toggle to the application. She creates a theme context and ensures all existing components respect it:

// Micaela's fix: Theme toggle that switches between light/dark
<div className="bg-white dark:bg-gray-900 text-black dark:text-white">
  {/* All existing content now respects theme */}
</div>

Then next, I call Lindsay Stewart, The Accessibility Advocate, who runs through the app and then adds an accessibility modal for screen reader settings, keyboard navigation help, etc:

// Lindsay's fix: New accessibility modal
<div className="fixed inset-0 bg-white p-6">
  <h2>Accessibility Settings</h2>
  <p>Keyboard shortcuts: Press Tab to navigate...</p>
</div>

Now hopefully you can see the problem with the code that Lindsay just added (hint: she hardcoded bg-white). She created a NEW component that Micaela never saw. Lindsay was focused on accessibility (ARIA labels, keyboard navigation, contrast ratios) and not on checking whether her new modal respects the existing theme system.

Now if a user tries to use this app:

1. They enable dark mode, causing the entire app to go dark
2. They open the accessibility modal
3. FLASH OF BRIGHT WHITE because Lindsay hardcoded bg-white

This is what should have happened:

// Correct: Modal respects theme
<div className="fixed inset-0 bg-white dark:bg-gray-900 p-6 text-gray-900 dark:text-white">
  <h2 className="text-xl font-bold">Accessibility Settings</h2>
  <p className="text-gray-700 dark:text-gray-300">
    Keyboard shortcuts: Press Tab to navigate...
  </p>
</div>

Now normally, it is Cassandra Hayes' job to check that all these features work together cohesively. So naturally, I would expect her to apply the fix above in this workflow. However, Micaela's theme work happens to be "lost in the middle" so Cassandra has weaker attention to the theme implementation details.

She might:

• Test the theme toggle and see that it works on main pages (check!)
• Test the accessibility modal and see that it opens and functions (check!)
• But she might not think to test: "What happens when BOTH features interact?"

Example 2: The Form That Never Forgets

If that illustration made no sense to you, let's consider another use case with Eesha Desai, The State Management Specialist.

Let's assume that on this same application, there happens to be a form with multiple steps:

• Step 1: Collects the user's personal information
• Step 2: Collects details about the user's preferences
• Step 3: Lists out all the information the user filled so that they can confirm and then submit

Now the above form was created by the general-purpose subagent, but by the time Eesha Desai is called, she notices that there is an issue with state persistence which causes the form to reset to step 1 when users navigate away from it. She fixes this form by adding localStorage persistence as you see below:

// Eesha's fix: Persist form progress
useEffect(() => {
  const savedStep = localStorage.getItem('formStep');
  const savedData = localStorage.getItem('formData');

  if (savedStep) setCurrentStep(parseInt(savedStep));
  if (savedData) setFormData(JSON.parse(savedData));
}, []);

useEffect(() => {
  localStorage.setItem('formStep', currentStep.toString());
  localStorage.setItem('formData', JSON.stringify(formData));
}, [currentStep, formData]);

Now there is something that Eesha failed to implement after she added the fixes above. Yes, she ensured that the form details persist, but she failed to update the handleSubmit() function so that the localStorage is cleared after a successful submission. This is what the handleSubmit() function looks like now:

const handleSubmit = async () => {
  await submitForm(formData);
  router.push('/success');
};

Obviously the problem with the above is that this is what the workflow now looks like for the completion of this form:

1. User fills out Step 1 and Step 2
2. User submits the form on Step 3
3. User wants to submit a SECOND form
4. User clicks "Start New Form"
5. Form opens at Step 3 with old data because Eesha's persistence is still holding the previous state

Now by the time we get to the last subagent call, Cassandra Hayes obviously has to validate that this form was indeed implemented well. I expect Cassandra to update the handleSubmit() function to what you see below, which represents what Eesha should have updated the function to:

// What Eesha should have added:
const handleSubmit = async () => {
  await submitForm(formData);

  // Clear persisted state after successful submission
  localStorage.removeItem('formStep');
  localStorage.removeItem('formData');

  router.push('/success');
};

So Cassandra checks, "Can a user complete the form from start to finish?" and she sees that yes, they can. But because Eesha's state management work is in the middle zone with "weak attention," Cassandra might not connect:

• "Wait, Eesha added persistence..."
• "...which means I should test: what happens on the SECOND form submission?"

Cassandra's attention to the recent conversation (her own analysis and that of Daniella Anderson who comes before her in the workflow) is strong. Her attention to what Eesha specifically implemented three subagents ago is degraded. She checks flows as if the app is stateless, forgetting that persistence was added.

The Irony: The Detective Who Can't Detect

Cassandra Hayes, The Feature Detective, exists for the purpose of catching these cross-feature issues. However, the "lost in the middle" phenomenon works against her when she's operating in a bloated context window.

A bloated context window affects the quality of Cassandra's holistic review because she's supposed to verify that everything works together. But the combination of these two phenomena working together might even cause her to re-introduce issues that middle subagents already fixed.

Why Learning This Mattered

Do you now see why it was important that I learned about tokens and context windows before embarking on this experiment? I am pretty sure that there is still a lot that I do not know and very likely many other factors that I am yet to consider. However, this is definitely a good factor to keep in mind as I work through this experiment.

Now you may be wondering, I just described the problem but provided no solution with explanation of why that may work better instead. Well, I do have a solution, but to prevent this post from getting too long, I'll save that for the next blog post.

As always, thanks for reading!