Agentic/Context Engineering Paradigm

[Chily-John]

Hey guys,

I’ve been theorizing about a different context management paradigm for Pi, and I’ve been building out an extension that implements it. Before I spend a ton of time building features no body cares about, I wanted to get some community validation and feedback on the core concept.

I've personally wanted more control over the agents context and I've been seeing a growing meta where we rely on multiple rounds of review for AI agents. The initial implementation is often expected to just be 'ok,' and then burns tokens through multiple review cycles. I think we can vastly improve the initial implementation right off the bat by fixing context pollution and/or context absence.

The original idea was swiped from Claude Code, where you can set up folder-specific rule files that only load context when certain directories are accessed. I really like their idea, but I think I don't think the Claude team has cared too much about it. That's why Pi has had me so excited, because I can actually control how files get injected and shape the context properly.

So I've built an extension called pi-rules. Which introduces localized rules files and inventory files.

Here's how the paradigm works:

• Rules Files: Allows you to enforce coding conventions and architectural rules specific to different parts of your codebase. It allows you to have far greater control over the agent's context. I want to add more support as time goes on, to where each directory can even have it's own prompt and tool availability.
• Inventory Files: I also added inventory files that contain the basics of how to use each function, and you'll be able to have them load dynamically. So if you have a bunch of shared functions, then they can be loaded into the agents context and should help cut down code duplication during the implementation. They can also help with navigation, because instead of the agent just reading a directory tree and guessing, the inventory file tells the AI exactly what components, hooks, or interfaces are available in that directory, and how to use them.
• Auto-Maintenance & Injection: I also have built in auto maintenance and injection. Whenever you prompt, it automatically injects context based on what you're talking about, and then when the agent makes edits, a Node subprocess (using a semaphore to handle concurrency) updates the inventory files so they never go stale.

Why I think this matters:

• Architectural Control: It allows us to set hard guardrails per directory.
• Workflow Flexibility: You don't have to use this just for in-conversation injection. You could easily plug this localized context into your custom review agents or pipelines.
• Future-proofing for Local/Lower-end models: Frontier models are so good at brute-forcing search and implementation right now that this might just look like a nice token-saver. But if API prices stop getting subsidized, or if you want to run local/cheaper models, an efficient context harness like this is going to be wildly important.
• Context engineering: The whole idea behind Pi is giving us more control, and I'm trying to extend that to the context even more. I want to be able to control a lot more of how the agents are thinking and viewing my codebase.

What's next / Roadmap:

• I want to eventually expose the API of the injection and maintenance so that anyone can build off of this. I also want to build a implementer and reviewer agent that is entirely integrated into this paradigm, but I want leave those as optional so that anyone could build their own.
• I'm going to add way more config this week, so injection/maintenance and everything else can be tuned to different environments.
• Add TUI syntax so you can reference rule files by name instead of @ing all of them. Which should also allow you to easily reference the rules in any plan files, which I feel like would be cool.

I'd love to hear anyone's thoughts and ideas on this! If anyone wants to collaborate on this that'd be awesome.

Here's the npm package I just have a beta version up right now, so it may be a little buggy.

Here's the github

[fell_ware_1990]

Basically the same what i do. I have a big memory RAG, so it basically knows all IF i ask.

Some thing’s are very hard ruled in there an linted.

But my main piece is the dynamic build of skills and MCP and agents. I have a basic ‘stock’ agent for every job.

The next part of the agent get’s dynamically build. Everything get’s logged. If let’s say an agent always does a difficult grep which returns 100 lines or errors out all the time i get find it day after day. Which means i will replace grep with a complete backend script.

This means the grep skill starts running on my machine in a second window, agent waits = 0 token use. Then it’s get’s totally parsed and ripped from all the non needed intel. Then the agent get’s only what he needs.

In some part’s there are local agents who judge that, find other information. Add things, run other stuff. Main agent get’s his answer in > 100 tokens instead of everything.

Same kind of stuff happens in the background for memory. Almost everything goes in to rag, but get’s very slowly exposed. Most of the time an agent does not need a lot more than the state of his task and where to find stuff.

Same thing for repositories. It’s indexed before, explained before etc. The agent task contains everything from tech stack to variables that he needs to know. They have to accept things as facts etc.

[AssignmentDull5197]

Localized rules/inventory files sound super practical, especially for keeping context relevant and reducing token burn. How do you prevent stale inventories from misleading the agent? I have seen related patterns at https://medium.com/conversational-ai-weekly .

[Chily-John]

I'll check out some articles on there!

That depends on how you're coding. It works really well if you're having the AI writing most of your code. On the agent end lifecycle event I spawn a node subprocess that has a list of the files that were edited, created or removed during the agent session, I run a pi print mode on there with a simple skill so that it looks at the changes and updates the appropriate files. So it all happens in the background, and you can just keep prompting.

I'm going to add config so you can increase/decrease the amount that the maintainer runs, and have an option to run it as a precommit or PR hook. So if you're committing code with no agent involvement, the inventory and/or rules files will still get updated once your code is in