- What's brewing in AI
- Posts
- š§š¼ Your AI needs access
š§š¼ Your AI needs access
Let AI read and write your docs. Keep things organised. Get grounded output.
Your AI needs access
Let AI read and write your docs. Keep things organised. Get grounded output.
Was this email forwarded to you? Sign up here.

Howdy, you bunch of amazing wizards.
Iāve been thinking about context management lately.
Many people stop at knowledge retrieval. Youāve connected AI to your docs, and thatās great. But agentic tools like Claude Code are booming right now: these are agents that can take action and change your context for you.
This matters because it keeps AI's work effortlessly grounded. When AI can read your latest briefs, proposals or project plansāand update them mid-conversationāyou stop re-explaining yourself. Your context always stays current.
Think about where your work context actually lives. Docs scattered across Google Drive? Notes in Notion? A folder on your laptop? In your head?
Can AI both read and write to that place?
Having AIs cut off from your context is becoming the modern version of organizational silos.
The difference is that people ask when they're missing information. Your AI assistant just makes something up.
Hereās one way Iāve solved this for myself.
My strategy context was siloed from my coding context
I'm building a data product these days. Iām scraping web articles, turning unstructured data into structured information.
Like most solo projects, I wear every hat: developer, product owner, marketer.
Previously, my strategy docs (e.g. positioning, messaging, ICP, value proposition) for the product Iām creating lived in Google Docs. I had a separate project in the regular Claude app to chat about them.
Meanwhile, all my coding happened in Claude Code CLI.
That meant my contexts were siloed. When coding, Claude didn't know my strategy. When strategizing, Claude didn't know my technical implementation. Every time I needed both perspectives, I had to re-explain everything.
Two simple ideas
First: strategy docs live in the codebase.

I created a /product folder in my repo:
These files live alongside the code, synced to GitHub. Any agent with access to the codebase can read them.
Second: different surfaces for different work.

I tried using Claude Code CLI for both coding and strategy work. That quickly became a disorganized mess.
Claude Code CLI is great for coding, but the chat organization is a messāyou can't even rename conversations. I didn't want my strategy discussions buried in there, impossible to find later.
Instead, I started using a different surface for each context:
Coding: Claude Code CLI

Strategy: Claude Code on the web

Both surfaces access the same codebase. Both can read my /product folder. When I do strategy work in the web interface, it can also write directly to it, so those changes are there next time I'm coding.
IN PARTNERSHIP WITH GRANOLA
Granola doesnāt simply generate a bunch of meeting notes. It actually takes your notes and makes them way better. This is AI at its best.
You know that feeling when you leave a meeting and immediately forget half of what you agreed to?
That's not a memory problem. When you're back-to-back all day, there's simply no time to process. No time to write the follow-up.
Granola helps you become the person who actually does what they said they'd do.
You take notes during the meeting. Just quick bullets, nothing formal. Granola transcribes in the background and turns those notes into clear summaries with actual next steps.
No more "wait, what did we decide?" moments. Just clarity. And follow-through.
Free month with the code WHATPLUGIN
ā¦
An example of how my strategy and code inform each other
My product uses LLMs to transform unstructured web data into structured information. This requires carefully written prompts to generate reliable output at scale.
Writing effective prompts requires deep understanding about what the product is trying to achieve, who it's for, and what tone fits. Instead of re-explaining this every time, I tell Claude: "Check the product folder for context on our ICP and positioning before writing this prompt."
Having direct access to the strategy docs helps Claude write solid prompts right off the bat.
Itās then relatively easy to get Claude Code CLI to set up end-to-end A/B tests of these prompts directly in my coding interface.
I then flip over to the Web UI and have Claude Code analyse the test results and give suggestions on whatās working best, and how to perfect the prompt.
The web UI gives me nice comparison tables, and since it has direct access to the prompts (my independent variables) implemented in my codebase, itās able to suggest targeted edits.

Once I know which prompt and LLM model combination I want to use, I tell Claude Code CLI and it deploys the prompt/model combo into production for me.
If I want to revisit this process later, the technical implementation isn't mixed with the analysis and refinement. They live in separate environments. That makes it easier for the agent to pick up the thread (strategy isn't conflated with coding in its context window) and easier for me to find my strategy conversations.
A few more examples on how Iām using this
Strategic prioritization. I was weighing a few specific directions to take my app in, and used Claude as a sparring partner to help me decide. I asked it to investigate the codebase and product folder to inform its recommendations.
Feature decisions tied to strategy. I was building a filtering system and faced a UX question that seemed purely technical but was actually strategic. I told Claude to think about my target audience. It read the product docs, understood who Iām building this for: users that need to drill down quickly through large datasets. It recommended an approach I wouldn't have thought of and the architecture to make it fast.
Marketing copy informed by code. When writing product messaging, I needed to describe what users can actually do (and details mattered). In the web UI, I could ask things like "check this copy for accuracy against the filter and sorting options we actually have in the appā.
Your move
I happen to use a codebase because I'm building software, but the same logic applies if you're running a consulting practice with client briefs, managing a content calendar, or coordinating a team.
You don't need to be coding for this to matter. I'm using Claude Code, but the idea is tool-agnostic.
Centralize your context somewhere AI can read and write to. And keep it organized so you donāt go crazy.
Break the silos for AI; youāll save time and get higher quality, grounded output.
Dario
Was this email forwarded to you? Sign up here.
Want to get in front of 21,000+ AI builders and enthusiasts? Work with me.
This newsletter is written & shipped by Dario Chincha.
Disclosure: To cover the cost of my email software and the time I spend writing this newsletter, I sometimes work with sponsors and may earn a commission if you buy something through a link in here. If you choose to click, subscribe, or buy through any of them, THANK YOU ā it will make it possible for me to continue to do this.
What's your verdict on today's email? |




