The Shell & Email
Is email the best way to work when working with multiple agents at the same time? Each email thread is a session. And it supports group conversations.
See what I built on Github.
With email. you’re not chained to a single company’s app or, even, your laptop. You can do it anywhere and email is the most versatile in poor network conditions, on top of that.
Email already solves the problem for working with people in an asynchronous and distributed way. Large language models get this, like they get the shell.
Background
We like the shell and the terminal that let’s us use it. And for practical reasons. The shell composes and enables interoperability with other applications without a gatekeeper. Once you get the hang of it, using the terminal is fun and liberating.
There is no coincidence that LLMs are most useful to us when harnessed to the shell. And if we need to work very closely with an agent, doing so from the terminal is best so we can be as close to the shell as possible.
I’m thankful for that. We mostly use Claude Code, Codex CLI, and others, such as OpenCode that uses the shell and are worked with by us on the terminal (uses the shell). We don’t have to use an iPhone App or some cloud based web app by a single company to use a computer productively.
However, there are clearly limitations when you must work with many agents. It’s dizzying. We often need to work asynchronously with agents working on different things. Stop. Do something else. Live life. Check on it a bit. Return to it easily on our own time, etc.
Again, email already solves the problem for working with people in an asynchronous and distributed way. That translates well when working with agents, and even other people and agents.
How I got here
After the first release of Machtiani over a year ago, I began feeding Machtiani’s answers back into its next instructions. I didn’t release until now to pursue this. An iterative instructions loop that drove a worker that is lightweight supervisor.
That lightweight supervisor can work with any agents already installed on your computer.
I found email be the most natural and liberating way to work with others and agents together.
See Machtiani on GitHub.
—David
RAGs to RIChes
When it comes to code generative AI, RAG (Retrieval-Augmented Generation) is like the internet for computers. However, the common RAG approach of chunking files and indexing isn't ideal for working with git projects. It deteriorates contextual awareness and creates a mismatch between code and natural language. We've developed a novel technique called RIC: Retrieval Input Compression. RIC leverages the strength of LLMs to find the correct files to answer your prompts. Here's how it works:
1. We index the git history and files statically.
2. We compress the information at the retrieval stage, retaining semantic meaning.
3. This gives the LLM context-fitting data to infer the exact appropriate files.
The results are astounding.
Video of a chat with 3 different git projects:
- Large (1500 files);
- Small (50 files)
- Medium (600 files).
I'm pleased to announce that we came up with a novel technique that leverages the strength of LLMs to find the correct files to answer your prompts. We're calling the strategy RIC: Retrieval Input Compression. We index the git history and the files statically. Then, essentially, we compress the information at the retrieval stage, which retains the semantic meaning. This gives the LLM context-fitting data to infer the exact appropriate files. It solves the apples to oranges problem and eliminates the necessity for file chunking. The results are astounding. We can chat with git projects at scale.
Here is a video where I chat with Algorand's indexer project, which ingests Algrorand transactions for ease of discoverability. It has nearly 400 files checked into git, and it works unreasonably well.