Read summarized version with
From clever prompts to serious context engineering
The way we used to work with AI was all about writing the perfect prompt – the more detailed, the better the results. But that’s changing fast. Now, the real gains come from setting up your AI to understand the bigger picture: your code, tools, workflows, and all the constraints that come with them.
When you give AI systems a clear understanding of what’s going on, developers can get a lot more done. They write better code and spend way less time fixing mistakes. Instead of just throwing prompts at the AI, teams are building a map of their project that the AI can explore and update over time.
Why prompts alone are no longer enough
There’s a big difference between tweaking your prompts and giving your AI a deep understanding of the project. In complex codebases, it’s not about how you ask the question, but what the AI knows about the project in the first place.
Relying on prompts alone can lead to some big problems:
- The AI only sees one small part of the project, not the whole design or how everything fits together.
- Every time you start a new session, you have to re-explain everything to the AI – from frameworks to naming conventions.
- The AI has a short memory, so if you’re working on a long task, it’s easy to lose track of what’s going on unless you remind it constantly.
- Different developers use different prompts and techniques, which can lead to inconsistent code quality and a lot of duplicated work.
But when you treat the AI like a key part of your system, you can avoid these problems. You design how it learns, what it knows, and what tools it can use – not just what you say to it.
Thinking in layers: project, feature, and task context
To get started with this approach, you need a solid information architecture. One way to do this is to break things down into layers:
- The big-picture stuff: tech stack, framework versions, architecture, code organization, and all that.
- The specifics of each feature: what modules and components are involved, how they interact, and what the user experience is like.
- The details of the task at hand: what you’re trying to accomplish, how you’ll measure success, and what constraints you’re working with.
Instead of cramming all this into one massive prompt, you can store each layer in a predictable place – like a repo file or a knowledge base – where the AI can grab it when it needs to. This keeps your prompts simple and makes sure the AI always has the right context.
From prompts to agentic, tool-rich workflows
The latest AI workflows are all about creating reusable building blocks that let AI agents work in a systematic way, rather than just reacting to prompts. These agents can:
- Instead of relying on the raw LLM, try using tools like code search, test runners, and static analysis to get the job done.
- Load context on the fly based on what you’re working on – whether that’s a specific file, a query, or navigating through a graph.
- To keep track of things across sessions, use structured notes, summaries, and knowledge files to maintain your memory.
When it comes to context engineering, you’ve got to decide what tools are at your agent’s disposal, how it finds relevant context, and how that context gets stored and reused.
Designing a persistent context graph
Think of a context graph like a map of how all the knowledge in your project is connected – and how an AI agent can navigate it.
- You’ve got entities like services, modules, APIs, data models, tickets, and tests – all the pieces that make up your project.
- Then there are relationships between these entities – like how one service talks to another, or how a PR fixes a particular incident.
- And finally, you’ve got access paths – how an AI can jump from a bug report to the relevant logs, PRs, and test cases using the right tools.
In the real world, this graph might be backed by a mix of source control, vector search, and databases – but the key thing is that it’s
- Always there, even when you’re not – surviving across sessions, sprints, and team changes.
- You can query and update it using tools, not just manual copy-paste – making it a powerful resource for your AI.
- And because it’s version-controlled, it evolves alongside your codebase with changes you can track.
Concrete patterns for developer workflows
We’ve found some practical ways to make context graphs work in everyday development.
One approach is to keep all the must-know context in the repo, so it’s easy to find and use.
- Create files like AGENTS.md, instructions.md, context.md, and memory.md to explain the rules, standards, and decisions that drive your project.
- To help the AI figure out how to behave, use instructions that are based on the folder structure – like having different rules for the backend and frontend.
- Keep your key diagrams, data contracts, and invariants in a format that’s easy for machines to read, so you can find them quickly when you need them.
Centralize access to all the knowledge that’s spread out across different tools
- Make it easy for the agent to search across all your documentation, tickets, Slack threads, and design docs by putting them in one place.
- Instead of storing all the content, just store pointers to it – like URLs or IDs – to keep things organized and avoid duplicates.
- Focus on indexing the really important stuff, like PR descriptions, postmortems, architecture decision records, and runbooks.
Supporting tasks that take a long time with summarization and memory
- Use autosummarization to keep track of the important decisions, questions, and tradeoffs from long sessions, and store them in a condensed form.
- Save these summaries in project memory files or external stores, so the agent can pick up where it left off later.
- Design your workflows so the AI can read its own notes before jumping back into a big refactor that spans hours or days.
Context as a team sport, not an individual trick
The biggest productivity boosts happen when you do context engineering at the team level, not just individual level – it’s like the difference between having your own script on your laptop versus using CI/CD in the repo.
- When you systematize context at the team level, new engineers can get up to speed faster because they inherit all the shared AI instructions, repositories, and memories.
- You’ll also have fewer problems when handing things off between dev, QA, and product, because everyone – and every agent – is on the same page, using the same knowledge base.
- And because the context graph has all the coding standards, security policies, and performance constraints embedded in it, you’ll see more consistent adherence to them – instead of having to hunt them down in a wiki somewhere.
This is similar to how we’ve moved from running scripts on our laptops to using CI/CD in our repos – context is no longer just a personal thing, it’s shared infrastructure that everyone can use.
Design principles for robust context graphs
If you want to make these systems work in the real world, there are some design principles that experienced teams swear by.
- So, what’s low coupling? It’s when you break down services and components into smaller bits, so you don’t have to load the entire codebase just to get the context you need.
- Then there’s convention over configuration – basically, you standardize where all your AI-related files live, how you set up your agents, and where you store your summaries.
- And let’s not forget context minimization. The idea is to start with the smallest amount of context necessary and only add more when you really need it, using tools to avoid cluttering things up.
- When your AI fails, don’t just tweak the prompts – take a step back and improve the context or the tools you’re using.
Getting started: an incremental roadmap
You don’t need some fancy platform to make context-engineered workflows work. For most teams, it’s about taking a pragmatic approach, which looks like this:
- First, get your local project context in order. Add some AI-focused docs to your repo – think project rules, architecture overviews, and coding standards – and make sure they’re easy to find.
- Next, introduce some basic AI tools. Configure them with clear instructions, give them access to memory files, and hook them up to your code search and test tools.
- Then, connect your external systems. Integrate your tickets, CI logs, and docs into one place, and start mapping out the relationships between them in a simple graph.
- After that, add some persistence and summarization. Enable automatic session summaries and store them as part of your project memory, so you can keep track of long-term tasks.
- Finally, standardize your AI setup as part of your team’s infrastructure. Version-control your AI configs, conventions, and context graph schemas, and treat them as shared assets that evolve over time.
From AI assistant to AI-native development environment
When you set up context-engineered workflows, you’re not just getting a fancy autocomplete – you’re creating an AI-native development environment that really understands your systems, constraints, and history. Developers can stop explaining everything to the AI and start designing the world it operates in – a persistent, tool-rich context graph that grows with your codebase and your team.
For teams that put in the work, the payoff is huge. You’re not just getting faster individual contributors – you’re building a development organization where humans and AI are on the same page, with a shared understanding of the system that they can evolve together.
