# TypeAgent, Microsoft Research's experiment in a single personal agent > microsoft/TypeAgent is sample code exploring how to combine language models with ordinary software into one personal agent that takes natural language requests, and the README is unusually explicit about the three principles that shaped it: distil models into logical structures, use structure to control information density, and use structure to enable collaboration between models, programs and people. **microsoft/TypeAgent** — Sample code that explores an architecture for using language models to build a personal agent that can work with application agents. - Repository: https://github.com/microsoft/TypeAgent - Stars: 748 · Forks: 108 - Language: TypeScript - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-typeagent ## The three principles behind the architecture TypeAgent is described as sample code exploring an architecture for building a single personal agent with natural language interfaces, leveraging current advances in language model technology. The goal, as the README states it, is to explore how to get work done by safely and efficiently combining stochastic systems like language models with traditional software components. Three principles emerged during that investigation, and each is applied across actions, memory and plans, which is the useful way to read the table. The first is to distil models into logical structures. For actions, that means finding translation patterns and replacing some model calls by applying the patterns. For memory, it means building ontologies from text. For plans, it means people, programs and models collaborate using a tree of thought. The second is to use structure to control information density. For actions, applications define discrete categories with dense descriptions of action sets. For memory, tight semantic structures fit into the attention budget. For plans, each search tree node defines a focused sub-problem. The third is to use structure to enable collaboration. For actions, humans decide how to disambiguate action requests. For memory, simple models extract logical structure from text. For plans, quality models, advantage models, language models, humans and programs collaborate to expand each best-first-search node. What is notable is that none of these principles is about making the model bigger or better. Every one of them is about adding structure around the model so that the model's role shrinks to the part that genuinely needs a model. That is the architectural bet. The stated ambition is human-like memory with super-human precision and recall for agent conversations, and the repository is explicitly a Python port exists too, so typeagent-py is the sibling to look at if you prefer Python. ## Structured RAG and the flow between actions and memories The memory design is called Structured RAG, and it is described as a new indexing and query processing approach used as the basis for agent memory. The claim is that it does substantially better than Classic RAG at answering questions about past conversations, with the examples given being what were the books we talked about and what step were we on in building the photo montage. Those two example questions are the point. A classic retrieval setup embeds text chunks and finds similar passages, which works when the question paraphrases the content. It works less well when the question is about the state of a project, where the answer is spread across many turns and the useful piece is a synthesis rather than a passage. Structured RAG is the attempt to index by logical structure rather than by text proximity. The second idea in the README is the flow between actions and memories. The example is that an action like adding a pickle ball game to a calendar from 2 to 3pm on Friday yields a memory, and that memory can become a parameter of a later action, like putting an hour of recovery time after the pickle ball game. That is the piece that makes a personal agent different from a chatbot, and it is where the principles pay off. An action produces a durable trace, the trace is indexed as structure, and the structure feeds the next action's parameters. The architecture that supports this is called AMP, and it integrates actions, memories and plans so the information flows naturally between them rather than through an explicit pipeline. The application of AMP to the web is a browser that lets web sites register actions through a JavaScript interface. That is the piece that would make it a personal agent for all applications rather than one application, and it is the piece that is hardest to get right, because it asks every site to expose its own actions in a form a model can call. ## The packages and the shell you start from The repository is organised as a set of packages under ts/packages, and the README names the three that matter. The TypeAgent Dispatcher explores applying structured prompting and a language model to route user requests to agents whose typed contract best matches the user's intent, and it is described as the main component of the personal agent. That is the piece that turns a sentence into a call on some other agent, and the typed contract is the interesting constraint: an agent declares what it can do in a typed form, and the dispatcher's job is to pick the right one and fill in the parameters. KnowPro explores how to implement agent memory using the ideas of Structured RAG, so it is the package where the memory design is actually coded. TypeAgent Cache explores how structured prompting with a language model can be used to cache action traces, and it is described as the integration that lowers cost and latency. Caching a model call is expensive to get right, because a cache hit has to be semantically equivalent to the original, and a structured representation of the trace is what makes that check possible. The starting point is the TypeAgent Shell, an Electron application for interacting with multiple registered agents through a single unified user interface. The README lists what it includes: a conversational interface for the single personal agent with voice support, the ability to collaborate with users to perform and dispatch actions to an extensible set of agents while answering questions and carrying on a conversation, conversational memory based on Structured RAG, and the cache integration. The setup instructions are per platform, with separate documents for Windows, WSL2, Linux on Ubuntu or Debian, and macOS, plus a more detailed guide in the TypeScript directory's README. The platform split is because the project runs models and tooling locally, and the setup differs enough on each that a single document would be unhelpful. ## Applying it to the web with registered actions The browser side is the most experimental part of the plan and the one to watch. The idea is a browser that lets web sites register actions through a JavaScript interface. Rather than the agent deciding what to click, each site exposes the set of things it can do, and the agent routes to the right one. That inverts the usual arrangement: instead of the agent modelling every site, the sites describe themselves. The reason this matters for the rest of the architecture is the typed contract. The dispatcher selects among agents by matching the user's request against a typed contract that the agent has declared, and a web-registered action is the same shape as any other agent's contract. So the same routing mechanism covers your own application actions and the actions of third-party sites. The security question is the obvious one, and the README does not pretend otherwise. A site that registers actions is making claims about what can be done with the user's data on that site, and a personal agent that acts across sites has to decide how much to trust each claim. That is exactly the kind of question the third principle, about structure enabling collaboration, is meant to frame: humans decide how to disambiguate action requests, which implies a human is in the loop for the ambiguous cases. The repository is at an early stage on this. The AMP architecture is described as being worked on, and the browser is the piece with the least settled design. If you are evaluating the project, that is the part to watch, because the rest of the design follows from whether it works. ## What this is for and how to read it The most important thing about this repository is that it says it is sample code. That is not a disclaimer, it is a description of the intended use, and the README is explicit that the goal of the team is to explore the architecture rather than to ship a product. The alternative interpretations do not fit. It is not a framework to build on, because a sample architecture does not promise a stable API. It is not an agent you deploy, because there is no product here to deploy. What it is, is a working implementation of an idea that a lot of people are talking about, written by people with the resources to try it properly and to publish the reasoning alongside the code. That makes it worth reading in a specific way. The three principles and the worked examples are the argument, and the code is the evidence. If you are designing an agent system, the questions to ask of this repository are whether the dispatcher approach to mapping a request to a typed action contract holds up in your domain, whether Structured RAG gives you better answers about project state than plain retrieval does, and whether the action-to-memory-to-action flow is the right shape for the tasks you have. The cost of engagement is real, and the README is honest about it. It is TypeScript and Electron, it runs language models locally, the setup is per platform, and the components are in separate packages, so you will be reading a lot of code to understand how the pieces fit. The shell is the place to start because it is the part that runs, and the dispatcher is the part to read closely because it is where the central idea lives. The comparison to make is with the other published agent frameworks and the other research samples. Most of them are libraries with a tool-calling interface and a memory store. This one is a statement about how you should structure the whole system around the model, with the model doing less and the structure doing more, and the reason to read it is the argument rather than the code. For anyone building on it, the licence is MIT, the default branch is main, and the last push was on 2026-10-20, so the work is active and the design is still moving. ## Conclusion Adopt TypeAgent if you are researching how language models can be wired into application actions, and you want a reference implementation with a working shell, a dispatcher and a memory design to read. Skip it if you are looking for a production agent framework, because the repository is explicitly sample code and the design is still in motion. Verify first by building the TypeAgent Shell on one platform using the setup instructions, since the components are split across packages and the dispatcher is where the routing logic actually lives. ## FAQ ### What is TypeAgent? It is MIT licensed sample code from Microsoft exploring an architecture for a single personal agent with natural language interfaces, combining language models with traditional software components. A Python port exists separately as microsoft/typeagent-py. ### What are the three principles behind the TypeAgent architecture? Distil models into logical structures, use structure to control information density, and use structure to enable collaboration. Each is applied to actions, memory and plans, so the pattern is to shrink the model's role by adding logical structure around it. ### What is Structured RAG in TypeAgent? It is a new indexing and query processing approach used as the basis for agent memory, described as doing substantially better than Classic RAG at answering questions about past conversations, such as what the books we discussed were or what step we were on in a task. ### Which TypeAgent package handles routing requests to agents? The TypeAgent Dispatcher, which explores applying structured prompting and a language model to route user requests to agents whose typed contract best matches the user's intent, and which the README calls the main component of the personal agent. ### How do you run the TypeAgent sample code? Start from the TypeAgent Shell, an Electron application, and follow the per-platform setup documents for Windows, WSL2, Linux on Ubuntu or Debian, and macOS, with a longer guide in the README of the TypeScript directory. The components are split into the dispatcher, KnowPro for memory and the cache packages. ## Sources - [Issues](https://github.com/microsoft/TypeAgent/issues) - [License: MIT](https://github.com/microsoft/TypeAgent/blob/main/LICENSE) - [microsoft/TypeAgent on GitHub](https://github.com/microsoft/TypeAgent) - [README](https://github.com/microsoft/TypeAgent/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-typeagent