Three months after publishing “Behind the Curtain,” I ran my first live workshop on AI agent development with MBA students in the Chasing Jarvis program at COTRUGLI Business School.
I expected questions about tools. Which coding agent is best? Should I use Claude Code or Augment Code? What about Cursor?
What I got instead was something far more useful: confusion at exactly the right moment.
One student raised her hand after I walked through the three phases. “So context engineering is Phase One,” she said. “What happens to context in Phase Two and Phase Three?”
I paused. And I realised she had found the single biggest gap in how I had explained the process.
Context engineering is not Phase One. It is the thread that runs through all three phases. I had described it as a starting point when it is, in fact, a continuous practice. Every good decision in Phase Two depends on it. Every audit in Phase Three benefits from it. Without it maintained across the entire build, even the most powerful orchestration platform produces chaos.
That question — and the dozens of workshop conversations that followed — is why this article exists.
This is the three-phase process, rebuilt. Not replaced. The phases themselves have not changed. What has changed is how I describe them, what I have learned about the points of failure, and above all, how I understand context engineering as the common denominator of the entire methodology.
First, a Reframing
In the first article, I named the phases: Context Engineering, The Build Phase, Production and Deployment.
That naming had an unintentional effect. By calling Phase One “Context Engineering,” I implied that context engineering was something you did once — at the beginning — and then left behind. Students interpreted the three phases as sequential and cleanly separated. Do the context work. Then build. Then deploy.
This is wrong, and it leads to real failures.
Here is the correct mental model: context engineering is a continuous skill you use across all three phases. The phases themselves are now better named:
PHASE 1 Research, Design & Foundations
PHASE 2 The Build Phase
PHASE 3 Debug, Audit & Deploy
Context engineering is not Phase One. It is the discipline that makes Phase One effective, keeps Phase Two coherent, and ensures Phase Three produces something you can actually trust.
Phase One: Research, Design & Foundations
The goal of Phase One is simple to state and surprisingly difficult to execute: by the end of it, your coding agent must have everything it needs to understand what you are building, why, and how.
This is pure context work. Nothing gets coded yet. No repositories are created. No environments are configured. The entire output of Phase One is a set of foundational markdown files that will serve as the shared knowledge base for everything that follows.
Starting With the Idea
I begin every project the same way. I open a Claude Project (i.e. it can be any LLM that you are using as your daily driver) and start talking. I use SuperWhisper — a voice-to-text tool — because I have learned that I explain ideas more fully and naturally when I speak than when I type. I describe the idea as I see it: what it does, who it is for, what problem it solves, and why I believe something like this does not yet exist or could be done better.
Then I ask Claude, which acts as my CTO, to do something specific: build me a foundational concept document. Not a technical spec. A research-grounded document that tells me whether this idea makes sense in the world, what analogues already exist, what features users would actually want, and what questions I have not yet thought to ask.
This is context engineering at its most creative. I am not constraining the AI — I am inviting it to help me understand my own idea more rigorously.
“The idea on the napkin is not the idea you should build. Phase One is the process of discovering what you are actually building.”
Once the concept document is solid and I have done further reading and thinking, I build the technical documentation. For most projects, this means four foundational files.
The Four Foundational Markdown Files:
architecture.md — The Architecture Document
The overall technical architecture: services, databases, external APIs, and hosting platforms. This is where I research the building blocks — the Legos — that fit together to deliver the product. Which database? Which authentication provider? Which AI model? Are there existing APIs I should integrate rather than build from scratch? This is not a complete specification; it is a clear statement of the chosen stack and the reasoning behind each choice.
2. blueprint.md — The Project Blueprint
The complete feature specification, broken into logical components: what does the front end consist of, what does the back end handle, where are the boundaries between them. This document also addresses economics. If this is a commercial SaaS product, what is the revenue model at various user scales? Is this viable to build? A coding agent directed by an incoherent business model will build an incoherent product.
3. ui_ux.md — The User Scenarios and UI/UX Document
How does a real user encounter this application? What is the onboarding flow? How do they navigate from the landing page to the core feature? What does each key screen display and what interactions does it offer? I am not designing pixels at this stage. I am describing functionality clearly enough that an agent can make sensible implementation decisions without me specifying every layout choice.
4. security.md — Security and Compliance Notes
This is the document most commonly skipped — and the one whose absence creates the most expensive problems later. What regulations apply? GDPR? Industry-specific requirements? Which authentication mechanism is being used? What data must be encrypted? What are the rate limiting requirements? Defining this in Phase One means the agent builds compliance in, rather than retrofitting it after a security audit reveals the gaps.
Some projects require additional documents. If you are building an AI-powered pipeline — a reasoning layer, a multi-agent orchestration system, a RAG implementation — add a dedicated Agent Orchestration document describing how the AI components connect, what models power them, and what data flows through them.
“Phase Two chaos is almost always a Phase One failure. Not of effort — of clarity.”
Phase One typically takes me three to seven days. This cannot be rushed. Not because the writing is slow but because good foundational documentation requires genuine thinking. Reading, researching, iterating, revising. Every hour invested here saves five in Phase Two.
Phase Two: The Build Phase
With your foundational markdown files ready, you move into Phase Two. The context you engineered in Phase One now becomes the operating system for your coding agent.
Setting Up the Environment
Create a project folder on your computer, named after the project. Inside it, create a subfolder called docs. Place all your Phase One markdown files inside docs. This structure keeps your foundational context co-located with your code, immediately accessible to any agent or developer who opens the project.
Next, create a GitHub repository named after the project. Set it to private or public depending on your needs. Connect this repository to your coding agent of choice. Most frontier coding agents — Claude Code, Augment Code, Codex, Open Code — support one-click GitHub connection with OAuth authentication. This is not optional. GitHub is your version control, your backup, and your deployment trigger.
I also strongly recommend installing the Playwright MCP at this stage. Playwright is a browser automation framework, and through its MCP integration, your coding agent can interact with your running application directly — navigating the UI, clicking buttons, submitting forms. This will matter enormously when you reach the debugging phase.
The Opening Prompt — Context Engineering in Action
Once the environment is configured, it is time to start building. And here is where context engineering shifts from a setup task to an active, continuous skill.
Here is the kind of opening prompt I use:
I’m building a SaaS application that allows users to deploy and maintain
their own second brain -- a compounding knowledge system. I’ve prepared
detailed project documentation: @architecture.md, @blueprint.md, @ui_ux.md,
@security.md Please read this documentation first. Identify any gaps or
improvements you see, and then prepare a detailed build plan.
Rules: (1) Push all substantial development milestones to GitHub
(2) Maintain and update documentation in parallel with development,
including both user guides and technical guides
(3) Update CLAUDE.md after every major build milestoneNotice what this prompt is doing. It is not asking the agent to “build a second brain app.” It is providing rich foundational context, inviting the agent to engage with and improve that context, asking for a plan before coding begins, and establishing the standing rules that will govern the entire build.
The quality of this opening prompt is a direct reflection of the quality of Phase One. If Phase One was thorough, this prompt is easy to write. If Phase One was thin, this prompt will produce a thin build plan.
The Context Window Problem
Here is the technical reality most beginner guides avoid: context windows fill up faster than you expect.
If you are working with Claude Sonnet and its 200,000-token context window, you can exhaust it within a focused work session. Code accumulates, documentation accumulates, your own messages accumulate. When you reach approximately 80% of the context window, you begin to see degraded output — inconsistencies, repeated work, missed requirements. The model is operating at the edge of what it can coherently hold.
I watch the context indicator in Claude Code the way a pilot watches the fuel gauge. Claude Code displays a circular indicator in the bottom right of the screen showing how full the context window is. When I approach 80%, I take action.
For this reason, I prefer to build with models that offer larger context windows. Claude Opus at one million tokens, or the GPT family’s one-million-token models, give significantly more runway per session. The trade-off is cost, but for complex production builds the reduced session management overhead is worth it.
When a session does approach its limit, the process is: create a handoff file. This is a markdown document summarising what has been built, what decisions were made, what the current state of the codebase is, and what the next steps are. You pass this handoff file to the new session. This is manual context engineering — you are bridging the gap the model cannot bridge itself.
The Three Layers of Agent Memory
Here is the fundamental problem with LLMs: by default, every new conversation starts from nothing. The model has no idea who you are, what you are building, or what was decided in your last session. For a one-off question, this is fine. For a multi-week build project, this is a serious limitation.
Memory is how you fix it. And there are three approaches — not competing, but complementary.
Layer 1: Markdown File Libraries
This is the most practical approach, and the one you should implement on every project. Most frontier coding agents support a persistent context file that loads automatically at the start of every session. Claude Code uses CLAUDE.md. Cursor uses .cursorrules. Open Code uses AGENT.md. This file is your agent’s standing brief — the rules, architecture decisions, and project-specific context that should inform every action it takes.
Critically, you must treat this file as a living document. After every major development milestone, instruct your agent to update it. If you do not maintain this file, it becomes stale context — worse, in some ways, than no context at all.
Markdown files are lightweight, readable, and native to LLMs. The trade-off is discipline: you must structure them well and keep them current. Medium complexity. Entirely learnable.
Layer 2: RAG — Retrieval Augmented Generation
RAG is the older paradigm for giving AI systems access to large document collections. You chunk documents into segments, convert those segments into vectors, store them in a vector database, and retrieve the most relevant chunks when the agent needs information.
It works — but it has real limitations. When you chunk a document, you lose the connections between sections. Cross-references disappear. Tables get fragmented. The system operates at roughly 80% accuracy on complex documents, and it requires meaningful infrastructure: a vector database, an embedding pipeline, an orchestration layer.
Do not reach for RAG because it sounds sophisticated. Reach for it when you have a large, heterogeneous document corpus — thousands of documents — that genuinely cannot be managed any other way.
Layer 3: The Curator — Long-Term Knowledge Compounding
This is the approach I have been developing for my own work, and it represents a fundamentally different paradigm. Rather than chunking documents and retrieving pieces, The Curator reads your sources and writes a structured wiki — entities, concepts, summaries, all interlinked. Every time you add a new source, it updates existing pages rather than duplicating. Knowledge compounds over time.
Through an MCP integration, a frontier model like Claude Opus can query this wiki graph directly — traversing relationships, surfacing connections you did not consciously make, and writing new findings back into the wiki.
The result is a second brain that genuinely grows smarter with use. For long-running projects and multi-year knowledge domains, this is the right architecture.
How to Layer the Three Approaches
These are not competing options. You layer them.
– Markdown files handle active project context — the current sprint, the current codebase, the current session.
– The Curator is your long-term intelligence layer — compounding knowledge across projects, across years.
– RAG has its place for specific large-scale retrieval scenarios where the others genuinely fall short.
“The agents that consistently outperform are the ones that know which memory layer to access — and when. That is what sophisticated context engineering makes possible.”
Phase Three: Debug, Audit & Deploy
When your coding agent delivers a build, your first instinct might be to move straight to deployment. Resist this instinct.
A built application is not a finished application. Phase Three exists to verify, harden, and ship — in that order.
The Debugging Sub-Phase
I start every debugging session manually. I run the application and test every feature myself, as a user, without shortcuts. I test the onboarding flow. I test error states. I test edge cases — what happens when a user submits an empty form, when a network call fails, when two features interact in unexpected ways.
When I find an issue, I do not just describe the symptom to my coding agent. I make a screenshot. I write a specific, factual description: “The submit button on the profile creation screen becomes unresponsive after the first file upload. The console shows a 403 error from the storage endpoint.” Specificity is context. Vague bug reports produce vague fixes.
For applications where automated testing is appropriate, the Playwright MCP is a genuine force multiplier. Here is the kind of prompt that works:
Run the application locally. Put on your user’s hat and test every feature
in depth. I have added the Gemini production API key in the .env file,
so you have explicit permission to test with live production API calls
-- we need real responses to verify actual behaviour. As you test,
take screenshots and add them to the user documentation so guides have visual
references. If you find any issues, debug and repair them,
then re-test until all features pass.That prompt does several things at once. It gives the agent explicit permission to test with live credentials — important because without this, agents default to synthetic responses that may not reveal real failures. It makes documentation creation part of the testing process. And it establishes a loop: find issue, fix, verify.
I want to be honest about the current state of automated debugging. It is not yet fully reliable. Browser testing consumes tokens at a higher rate than you might expect. Login walls — especially OAuth flows — are difficult for agents to navigate repeatedly. There are still classes of UI bugs that a human eye identifies immediately but an agent misses entirely. The right approach today is hybrid: use Playwright MCP for repetitive feature coverage, but do not remove yourself from the testing loop.
The Audit Phase
When debugging is complete, I run security and optimisation audits. And I run them with multiple models.
My current standard audit stack is Claude Opus, GPT, and Gemini Pro. Each model has different training emphases, different blind spots, and different patterns of attention. Running all three gives the broadest possible coverage. I ask each one to examine the codebase specifically for: authentication implementation, data validation, API key exposure risks, injection vulnerabilities, unprotected endpoints, and performance bottlenecks.
The findings are never identical. Each model surfaces different concerns. I compile the results, prioritise by severity, and instruct my coding agent to address everything material before the application goes live.
“The three-audit approach is not perfectionism. It is professional practice. Each model sees things the others miss.”
All fixes go to GitHub before deployment. GitHub is not just version control in this methodology — it is your source of truth, your deployment trigger, and your recovery mechanism. If an agent makes a deployment error, GitHub is what lets you roll back cleanly.
Deployment — The CTO LLM Concept
Deployment strategy depends on your architecture. For most modern AI-powered applications, the primary options are Firebase, Google Cloud Run, DigitalOcean App Platform, Vercel, Hostinger and others. The right choice depends on your stack, expected load, cost constraints, and compliance requirements.
For this decision, I use what I call a CTO LLM — a Claude instance loaded with the project’s foundational documentation and a prompt asking it to recommend the right hosting approach given the specific stack and requirements. This is context engineering applied to infrastructure: the model needs the full picture to give you a genuinely useful recommendation, not a generic list of options.
When you connect a coding agent to production infrastructure, give it scoped access — project-specific credentials, not master admin access. Use service account tokens with the minimum necessary permissions. Agents will do exactly what they are configured to do, including mistakes. Scoped access limits the blast radius of misconfiguration.
Once deployment is complete and the application is live, instruct the agent to update all documentation — technical guides, user guides, and deployment notes — to reflect the production state. This documentation becomes the handoff package for future sessions, future team members, and future you.
The Common Thread
After running workshops with students at COTRUGLI »Chasing Jarvis«, after building multiple production applications using this methodology, and after iterating on these phases through two years of hands-on work, one thing has become completely clear to me:
The difference between a clean, productive build and a debugging nightmare is not the coding agent. It is not the model. It is not the platform.
It is context.
Rich context going in means coherent output coming out. Stale context means contradictions in the code. Missing context means the agent makes assumptions — and those assumptions will not match your intentions.
Context engineering is the continuous practice of ensuring the right information is available to the right agent at the right moment, across all three phases. In Phase One, it means building thorough foundational documentation. In Phase Two, it means maintaining memory files, managing context windows, and writing precise prompts. In Phase Three, it means providing specific bug descriptions, auditing comprehensively, and deploying with documented infrastructure decisions.
This methodology is agnostic to which coding agent you use. The three phases apply equally whether you work with Claude Code, Augment Code, Codex, or Open Code. The memory layers apply across all platforms. The auditing practice applies regardless of the underlying model.
What it is not agnostic to is the discipline you bring to it. These phases cannot be rushed. The foundational documents cannot be thin. The memory files cannot be left to go stale.
“Context is not a task on the checklist. It is the entire game.”
The student in my workshop who asked what happens to context in Phase Two and Phase Three was asking exactly the right question. The answer is: you tend to it, deliberately, at every stage. You treat it as the primary variable in every interaction you have with your coding agent.
That is the shift. From thinking about context as a starting condition to treating it as an ongoing practice. From building with AI to building with AI well.
Start with context. Build with discipline. Deploy with confidence.
About the Author
Dr. Tali Režun is a Serial Entrepreneur, Business Developer, and Academic at the forefront of frontier technologies. As Vice Dean of Frontier Technologies at COTRUGLI Business School, he leads AI innovation initiatives and shapes MBA curricula for the next generation of technology leaders. With over 30 years of entrepreneurial experience — founding and scaling ventures including The Curator, Lumina AI, Moj AI, Block Labs, CR Systems, 4thTech, Immu3, PollinationX, and Online Guerrilla — he bridges cutting-edge research in AI and Web3 with practical business transformation.
– https://talirezun.com/
– https://x.com/talirezun
– https://www.linkedin.com/in/talirezun
– https://www.researchgate.net/profile/Tali-Rezun
– https://github.com/talirezun
Sources & Further Reading
Režun, T. (2026). Behind the Curtain: The Three-Phase Process I Use to Build Every AI-Coded Product. Medium. https://medium.com/@talirezun
Anthropic (2024). Building Effective Agents. anthropic.com/research/building-effective-agents
Augment Code Intent Documentation. docs.augmentcode.com/intent/overview
Karpathy, A. (2025). Context Engineering and the Future of AI Programming. karpathy.github.io
Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. arXiv:2005.11401
METR (2025). Measuring the Ability of Language Models to Follow Instructions in Complex Development Tasks. metr.org
Osmani, A. (2025). The Future of Agentic Coding. addyosmani.com
Disclaimer
Research and Educational Purpose. This article is published for research and educational purposes only. The content represents personal experiences, observations, and analysis based on extensive hands-on experimentation with AI agent technologies, as well as feedback gathered from MBA workshop participants at COTRUGLI Business School.
No Commercial Relationships. The author has not been compensated, sponsored, or otherwise financially supported by any of the companies, platforms, or tools mentioned in this article, including Augment Code, Anthropic, OpenAI, Google, or any other technology provider referenced herein. All opinions and assessments are based solely on independent research and practical experience.
Evolving Landscape. The AI agent ecosystem is developing rapidly. Tools, platforms, protocols, and best practices referenced in this article may be superseded, deprecated, or fundamentally changed by the time you read this. Always verify current capabilities and recommendations with primary sources and official documentation.