Context engineering with AI: the system I built to amplify my work

The documentation that had been lying dormant in so many companies, adding little value, suddenly becomes their biggest asset.

FELIPE POLO
CEO Orbitant

I’ve spent more than ten years in tech, and the last six months have been the most transformative in how I manage my work. The reason isn’t that I started using AI — it’s that I stopped using it as a loose tool and built a system around it. The distinction that makes this possible is called context engineering with AI, and it’s what separates a one-off use of AI from something that gets better over time.

If you’d rather watch the demos live, the full session (in Spanish) is available on YouTube.

From prompt engineering to context engineering with AI: the distinction that changes everything

Most people use AI the same way: they write a prompt, get a response, and start over — because every conversation begins from scratch, and you have to explain who you are, what context you’re in, and what you already know about the problem.

While prompt engineering works on the quality of the question, context engineering works on what’s already available before that question arrives. Andrej Karpathy — the person who led AI at Tesla and one of OpenAI’s original founders — popularized this idea in early April with a concrete argument: a structured wiki is far more powerful than a RAG system because using the wiki creates a compounding effect. Every output you produce can feed back in as input for the next conversation, and what you end up building isn’t a collection of documents but a knowledge network that grows.

Documentation stops being a drag the moment it becomes active context for AI. I see it in client projects: data stored for twenty years for compliance reasons, with nobody ever putting it to use, suddenly turning into an enormous asset. And it makes sense, because structuring that material used to take months of manual work — but now the cost of generating good documentation trends toward zero, since AI can organize information even from raw notes. At the same time, its value skyrockets, because that same documentation becomes the context that lets agents work effectively.

The architecture I use to manage all of this has three layers:

• Raw files: notes, ideas, meeting transcripts, Twitter bookmarks, Telegram messages I send to myself whenever something catches my attention. At this point I don’t process anything — I just capture.
• Wiki: AI enriches, classifies, and connects those files, creating linked notes, tags, and categories. This is where the network gets built.
• Schema: the rules of the game. It includes the categories I use, the naming conventions, the possible statuses, the reference tone… without this, the wiki would descend into chaos.

The tool and the five agents that make up the system

To manage all of this I use Obsidian, a note-taking app that works directly on local Markdown files. It runs with no server and no paid subscription, and all the data is mine. What interests me most isn’t its simplicity, but that it lets you create WikiLinks between files, and those relationships translate into a visual graph. When AI has access to that graph, it can pull threads in ways I never would have anticipated: it connects an idea about AI agents with an article I bookmarked on Twitter three weeks ago and with a meeting from last month.

I’ve built the agents with Claude Code and distributed them as plugins on GitHub. A mega-agent that does everything is a mistake — the context you give it is too diffuse, and the output shows it — so I prefer several specialized agents, each with a specific purpose and the minimum context it needs to do the job well.

The five I currently use:

➤ Wiki Manager: the librarian. It ingests the raw files, enriches them, and adds them to the wiki with the right connections. It cleans up orphan notes, heals broken links, and keeps the network coherent. I run it with ingest when I start the day and with link when I close it out.

➤ Chief of Staff: the operator. Every morning, today creates a daily note for me with email triage — across several accounts in parallel — the day’s tasks from Asana, and a summary of where I stand against my strategic goals. At the end of the day, close of business processes everything that happened, indexes the day’s meetings, and updates the mini-CRM I keep in the wiki for every person I interact with.

➤ Coach: the one that pushes me hardest. On Sundays, I ask it to help me plan the week. It reads the context from the last seven days, sees my tasks, my goals, and the gaps in my calendar, and proposes a day-by-day plan. On Fridays, review gives me a performance review based on everything I’ve written in that week’s journal. The highest score I’ve earned so far is a 6.

“You’ve been complaining about this in your journal for three weeks straight. And yet, your time isn’t going there.”

That’s how the Coach talks to me; it’s hard to argue back.

➤ Content editor: It manages my content production for LinkedIn, the newsletter, and Twitter. It doesn’t write for me — the output sounds canned — but it proposes the weekly schedule based on my analytics and gives me feedback on what I write, applying the principles from the business-writing books I’ve fed it as context.

➤ Thinking Partner: the one that challenges me. the one that challenges me. Challenge takes an idea of mine and searches my entire wiki for arguments to rebut it. It doesn’t go to the internet — it uses my own notes, transcripts, and journals, which turn out to be the most useful source for spotting holes in my arguments before I defend them in public.

How to get started without losing your way

What you see here is the result of six months of iteration. You don’t need that long to reach something useful, but it’s worth not trying to build the complete system from day one. These are the steps I’d recommend:

1. Install Obsidian and Claude Code. Both are free. Inside Obsidian, create this basic folder structure: /raw for raw notes, /wiki for processed notes, /systems for the rules of the game.
2. Adopt the daily-note habit. It doesn’t need automation at first. Open a note, write down what you have to do, what you’ve decided, what’s worrying you. That’s the context AI needs to start genuinely helping you.
3. Connect to your tools via MCP. The fastest way to see results: connect email, Asana, and Slack. Asking questions about your own context in real time completely changes how you interact with AI.
4. Build your first small agent. Pick a task you repeat every week, describe it to Claude Code, iterate, and version it on GitHub.

The principle behind all of this holds whether you lead a company or write software. If you’re a developer, the relevant context is the architecture decisions you made six months ago, the tickets you resolved, the patterns that repeat across projects. All of that, well organized and accessible to AI, multiplies the quality of what you produce — not just the volume.

This pattern raises interesting questions when you move it to team or project scale: what changes architecturally, when it makes sense versus the model’s native context, what limitations show up when you stop being an individual user. Those are questions for another time. The one I do have answered is the one from the start: when context works for you, every conversation with AI begins from a higher level than the last — that’s the compounding effect — and once you see it, it’s hard to go back to working any other way.