Halo: how I'm building a team's working memory

Over the past few weeks, I’ve been building Halo — a working prototype that brings together team context from Tracker, Wiki, meetings, and other internal sources. You can ask it questions such as “What changed this week?”, “Why did we make this decision?”, or “Who is responsible for this now?” and get an answer with dates, links, and an explanation of the evidence behind it.

You can see the project on the Halo page. Here, I’ll take a closer look at why we need working memory in the first place, why conventional search proved insufficient, and how I’m building the prototype around real questions from a design team.

The context exists, but it’s scattered

A team generates a great deal of useful context every day. Statuses and assignees change in Tracker. Risks are discussed and decisions are made in meetings. Goals, processes, and specifications live in Wiki. Staff shows people’s roles, while Calendar can help reconstruct the sequence of events.

The problem isn’t a lack of information. The problem is that answering a single work-related question often means manually checking several systems:

find the task and review its status history;
remember which meeting it was discussed in;
open the summary and find the wording of the decision;
check Wiki to see whether the goals have changed;
confirm who is now responsible for the next step.

Each system works perfectly well on its own. What gets lost is the connection between them. A few weeks later, the task is still there, but the rationale behind the decision lives only in a meeting summary or in the memories of a few participants.

What I mean by working memory

Halo isn’t another Wiki or a chat that “knows everything.” I see it as a layer on top of the systems a team already uses. It doesn’t ask the team to move its processes somewhere new; instead, it connects existing entities:

tasks and their status changes;
meetings, participants, and recorded decisions;
Wiki pages, goals, and projects;
people, roles, and areas of responsibility;
links between all these objects.

Working memory isn’t a document archive. It should be able to show what happened, when it happened, what it relates to, and where the fact came from. That’s why Halo cares not only about text, but also about events: a task moved from inProgress to closed, a decision was recorded in a meeting, or a project’s assignee changed.

Why a graph, rather than just search

Search is good at answering, “Where does this phrase appear?” But most work-related questions are structured differently. “What changed in the project after the sync?”, “Which decisions are related to this task?”, and “Who took part in the discussion, and who is responsible now?” are questions about relationships and time.

That’s why I organized the team’s context as a graph. In it, a task can be connected to a project, meeting, decision, person, and Wiki page. Every connection has a source, and every change has a date. This layer helps you do more than find a document: it lets you follow the chain:

project → meeting → decision → task → status change
                         ↘ assignee

A graph doesn’t make an answer automatically true. It simply provides a verifiable structure: every conclusion can be traced back to a specific task, page, or meeting.

What a Halo answer looks like

I want an answer to be immediately useful without hiding uncertainty. So it has several layers:

Brief conclusion — a plain-language answer to the question.
Facts and dates — exactly what happened and when.
Sources — links to Tracker, Wiki, and meetings.
Why this answer — the changes and connections that support the conclusion.
Limitations — what is missing when the available data is insufficient.

For example, when answering, “What changed in the component?”, it isn’t enough to restate the task’s current description. The history matters: when the task was created, which meeting led to its status changing, where the decision was recorded, and who became responsible for it.

If the relevant fact isn’t in the graph, Halo should say so directly: “I couldn’t find it.” For a work tool, an honest gap is more useful than confident, plausible-sounding text. An answer like this shows exactly what needs to be checked or added to the sources.

From chat to exploration

Chat is a convenient entry point, but it isn’t the whole product. An answer often raises another question: what is this task, how has its status changed, who was involved, and what documents are connected to it?

That’s why the prototype includes Explore. From an answer, you can open a task, person, or decision and inspect the history of its connections. This is an important difference from a conventional AI‑generated summary: rather than being confined to generated text, the user can explore the original work context.

Workflows instead of a single empty field

Not every work-related question needs an open-ended chat. Many tasks recur: preparing a weekly update, getting ready for a 1:1, returning from vacation, finding blockers, or compiling decisions from meetings.

For these, I’m building workflows — ready-made recipes that run on top of the same memory. The user selects a period, participants, or project, and Halo knows which sources and connections to check. This makes the results more consistent and lowers the barrier to entry: there’s no need to invent the perfect prompt every time.

What happens under the hood

Several parts are already running in the prototype:

Ingest retrieves available data from work systems and maps it to a shared model.
Context graph connects tasks, meetings, documents, people, decisions, and events.
Chat turns a question into a context search and assembles the answer.
Explore displays entities, change histories, and adjacent connections.
Evals verify whether the system finds the right facts, preserves its sources, and can acknowledge when data is missing.
MCP provides agents with the same context, so they don’t have to begin with a blank slate.

Access control is also crucial. Halo should see exactly what the user can see in the source systems. If someone doesn’t have access to a task or page, it must not appear in either the answer or the source list.

Why MCP and agents matter here

I work in Cursor almost every day, and I’ve noticed a consistent pattern: an agent speeds up work when it has high-quality context. In a repository, that context consists of the architecture, rules, documentation, and a clear task. Within a team, similar context is usually scattered across tickets, Wiki pages, and meeting summaries.

If you give an agent only the task description, it may be able to write code or text, but it won’t know why the team rejected a similar solution a month ago. Give it working memory, and it can first check related decisions, current goals, and assignees.

That’s why I’m designing Halo as more than a human-facing interface. The MCP‑layer allows an agent to ask the same question and receive structured context with links to the sources. The person and the agent work from the same verifiable memory, rather than from two different retellings.

Why I started with a design scope

At this stage, Halo isn’t a product “for every company.” It’s a working prototype tailored to the context of a design organization. A narrow scope is useful here: I know the real entities, the team’s language, and the questions that come up every day.

This means I can test the system with practical questions rather than abstract demo queries:

what changed in the design system this week;
which decisions were made in the latest syncs;
why a process or status changed;
which tasks are linked to the quarter’s goals;
what someone needs to know after returning from vacation;
where the available data is insufficient for a confident answer.

This quickly reveals real problems: duplicate entities, outdated connections, incomplete summaries, ambiguous names, and events without dates. These details have a greater impact on the quality of working memory than an impressive chat interface does.

What I’m testing now

For me, the main question isn’t, “Can the model produce an eloquent answer?” Modern models can do that without Halo. I’m testing something else:

does the answer save time compared with manual searching;
can every important conclusion be verified quickly;
can the system reconstruct the sequence of changes;
can it distinguish a recorded decision from an assumption;
does it notice contradictions between sources;
does it know when to stop if there isn’t enough data;
does the same context help agents complete real tasks?

The answers to these questions emerge only through use. Right now, it’s more important for me to gradually add real workflows, build evals, and see where Halo goes wrong than to rapidly expand the list of integrations.

Where the project is heading

The immediate goal is to make working memory reliable enough for recurring tasks: weekly updates, meeting preparation, context recovery, and decision exploration. At the same time, I’m testing how a single context layer can serve both the product interface and agents through MCP.

For now, it’s a living prototype: some parts already work, while others change in response to the first real questions. I’ll periodically write about how Halo performs in practice, which connections prove genuinely useful, and where the idea of working memory collides with reality.

Open the Halo page →