777-1: My Female Employees, Except Nancy, Are Context Engineers, Not Just Specialists
Published: December 9, 2025 - 6 min read
Yes, I know. I said in the previous blog post that I was going to introduce the projects. But you see, it is very important that we get this out of the way first.
I'm not really sure how to smoothly introduce you all to this, so I am just going to go straight to the point. I introduced all my subagents to you in this post. Here is a brief recap of all their names and job titles in the order in which they will be called in this experiment:
- Amber Williams - The Mobile-First Perfectionist (responsive-mobile-optimizer)
- Kristy Rodriguez - The "Does It Actually Work?" Enforcer (functionality-completeness-tester)
- Micaela Santos - The Design System Guardian (ui-consistency-design-systems)
- Lindsay Stewart - The Accessibility Advocate (accessibility-wcag-compliance)
- Eesha Desai - The State Management Specialist (state-management-data-persistence)
- Daniella Anderson - The Code Quality Specialist (code-quality-typescript-practices)
- Cassandra Hayes - The Feature Detective (cross-feature-integration-ux-flow)
Every single one of them is a context engineer in this experiment. Before I explain how, let's define the term:
Context engineering is the practice of providing the right information to an AI at the right time, in the right amount, to produce optimal outputs.
Now let me explain how my subagents act as context engineers.
The Lazy Prompt Problem
When I want to build an application, especially in a lazy way, a starting prompt I might provide to the model looks something like this:
Build a personal budget tracker where users can add income and expenses,
see their current balance, and view their spending breakdown by category.
Include a dashboard with charts showing monthly trends.
Now, notice that the prompt above misses a lot of things you would expect in a good prompt. Sure, it provides the details about the app's expected functionalities. However, it fails to specify:
- Responsive requirements
- Accessibility standards
- State management patterns
- Error handling expectations
- Complete functionality definitions
These missing specifications would have provided more context about the application to whatever model you are working with. Because of the missing specifications, Claude makes multiple assumptions to fill the gaps. It works if you are building an application for fun. However, you probably want to be specific for enterprise level applications where you have a target audience and you fully understand their needs and requirements.
The Overloaded Prompt Problem
Now let's say I transform that prompt into something more robust like this:
Build a personal budget tracker with the following requirements:
RESPONSIVE DESIGN:
- Mobile-first approach with breakpoints at 320px, 768px, 1024px, and 1440px
- Hamburger menu on mobile that contains all navigation items
- Touch-friendly targets (minimum 44x44px)
- No horizontal scrollbars at any viewport width
- Charts must resize appropriately on all screen sizes
FUNCTIONALITY:
- Full CRUD operations for income and expense entries
- Category management (create, edit, delete categories)
- Date range filtering for all views
- Search functionality across all transactions
- Export data to CSV
- Recurring transaction support
- All buttons must perform real actions, no placeholder toasts
UI/DESIGN SYSTEM:
- Maximum 3 primary colors with consistent usage
- Systematic spacing scale (4px, 8px, 16px, 24px, 32px)
- Consistent button styles (primary, secondary, danger variants)
- Modern footer with navigation links and social icons
- Dark mode toggle that affects all components
- Loading states for all async operations
ACCESSIBILITY:
- WCAG 2.1 AA compliance throughout
- Minimum 4.5:1 contrast ratio for all text
- All interactive elements keyboard accessible
- Proper ARIA labels on icons and charts
- Screen reader friendly transaction announcements
- Focus indicators on all interactive elements
- Skip to main content link
STATE MANAGEMENT:
- All data persists to localStorage
- Form state survives page refresh
- Filters and preferences persist across sessions
- Proper state isolation between components
- Forms clear after successful submission
- Optimistic UI updates with error rollback
CODE QUALITY:
- TypeScript interfaces for all data models
- Proper error boundaries
- Custom fonts loaded via next/font
- Components under 200 lines each
- Consistent file naming conventions
- Proper use of Next.js App Router features
INTEGRATION:
- Authentication system with login/signup/logout
- Dashboard reflects real-time balance updates
- Category deletion handles existing transactions gracefully
- Theme toggle affects charts and modals
- Help documentation for budget planning features
- Complete user flow from signup to first transaction
Well now we have another issue. The prompt now contains too much context (or simply put, too much information about the expected requirements and features). There is a chance that the model might fail to implement certain features because it is being overloaded with all of them at once.
Now when I build applications with Claude, I usually start off with a prompt similar to the above, except I then ask Claude to break it down into multiple implementation phases in the planning mode and store the phases in a document. Then we work through all the phases together. This is almost like prompt chaining or perhaps prompt decomposition where you break down all your functionalities into steps and then provide them to the model.
The Sweet Spot: Just-in-Time Context
So now, you may be wondering, what is the sweet spot? How much requirements or context should I provide to the model for optimal performance? Well, frankly, I don't know.
I do know that the Prompt Engineering Toolkit is supposed to have an algorithm that helps the average person. And, the average person is lazy and will not provide all the requirements to their prompts whether at once or sequentially. Hence, maybe this Prompt Engineering Toolkit is not just about the algorithm, but also about building and making available well defined and tested subagents that increase the model's chances of always meeting even requirements that are not explicitly stated in the prompt.
Let me explain further.
Let's look at our lazy prompt once again:
Build a personal budget tracker where users can add income and expenses,
see their current balance, and view their spending breakdown by category.
Include a dashboard with charts showing monthly trends.
Because it is missing context information about a number of requirements, my subagents essentially act as context engineers to ensure that the application meets a "golden standard" and is sophisticated, regardless of how lazy the initial prompt is. Hmm, the picture of the final application is starting to look just a teeny tiny bit clearer now.
You see, when the general purpose subagent is done building the application based on the user's requirements, my context engineers come into the picture one by one, following a specific order. When they evaluate an application to improve it, they technically provide domain-specific context just-in-time rather than all at once as seen with the robust prompt above.
Also, I want to stress one more time that the order in which I call these subagents matters.
Why This Order Works
1. Amber Williams - Responsive First
- Context: Layout must work everywhere
- Why first: Affects all subsequent decisions
2. Kristy Rodriguez - Functionality Second
- Context: Features must actually work
- Why second: No point styling broken features
3. Micaela Santos - UI Consistency Third
- Context: Visual coherence
- Why third: Now you know what you're styling
4. Lindsay Stewart - Accessibility Fourth
- Context: WCAG standards
- Why fourth: Applies to completed UI
5. Eesha Desai - State Management Fifth
- Context: Data persistence patterns
- Why fifth: Features exist, now make them persistent
6. Daniella Anderson - Code Quality Sixth
- Context: TypeScript, patterns
- Why sixth: Refactor working code
7. Cassandra Hayes - Integration Last
- Context: Cross-cutting concerns
- Why last: Everything exists, now connect it
Do you see now? This experiment is not just going to attempt to improve upon prompt engineering principles but also show the importance of context engineering.
What I Hope to Achieve
By the time I am done with this experiment, I don't want to simply define an algorithm for prompt engineering. I want to improve the markdown definitions of all my context engineers. By the time I am done with this experiment, it should almost look like I sent Amber, Kristy, Micaela, Lindsay, Eesha, Daniella and Cassandra on a 7-day long training workshop and they returned smarter and more efficient at their work.
I know it's just 7 applications right now, but they are quite a wide range of apps, so they should be a good start. And remember, this is supposed to be the project that never ends...
As always, thanks for reading!