Knowledge
and memory.
Agents start with your team's docs and notes from earlier work. Before finishing, they record what they changed, why, and what still needs doing. Those notes help the next agent or reviewer pick up where they left off.
The agent reads your docs and earlier notes.
It makes the change and checks the result.
It records what changed, why, and what comes next.
The next run can read the new notes too.
One knowledge base per team.
Each team has a knowledge base for architecture notes, coding conventions, runbooks, and incident reports. Team members maintain these files and choose which ones to share with the rest of the organization.
Private and shared folders
Files in private/ are available to your team and its agents. Files in shared/ are available to everyone in the organization and their agents. To share a document or folder, move it from private to shared.
Use subfolders to organize your docs. You can upload images and other files too, so a runbook and its diagrams can stay together.
conventions/migrations.md
incidents/2026-08-cgroup-race.md
architecture/egress-lanes.png
glossary.md
Share useful docs across teams
Every agent run gets a copy of other teams' shared/ folders alongside its own team's docs. For example, the platform team can share an architecture guide that agents working for the application team can also read. Only members of the team that owns a knowledge base can change it.
Your team maintains the docs.
Use the Knowledge page to upload, organize, and share files. Agents can read these docs, but they cannot update the knowledge base. They save their findings as task memory. Your team decides what to add to the docs.
Edit local files directly
In local mode, the files live under ~/.triagefactory/teams/<team>/kb/. You can edit them with your usual editor and refresh the Knowledge page to see your changes. Hosted deployments use the same folder layout in shared storage.
Check docs against the code
Docs can become outdated. Agents are instructed to check them against the code. If the two disagree, the agent should follow the code and flag the difference in its notes.
What the agent receives.
Triage Factory copies the relevant docs and saved notes into the agent's workspace before it starts. The agent can read them throughout the run.
Docs and earlier notes
The agent's workspace
_tfac/knowledge/ This folder contains the team's private and shared docs, plus other teams' shared docs under org/<team>/. The agent also gets a file list with the first line of each document to help it find what it needs. Changes to this copy are not saved back to the knowledge base.
_tfac/entity-memory/ This folder holds notes from earlier conversations on this task and other tasks for the same PR or issue. Recent notes are included in the agent's first message; older notes are available to search. A copy of the original task details preserves exact names, titles, and PR numbers. The agent can also use memory load to look up notes for another PR or issue.
Leave notes for the next person or agent.
Before a conversation finishes, the agent must save a memory file. It records the work done, the reasons for its decisions, approaches it ruled out, and anything left to do. If the file is missing, Triage Factory asks the agent to write it.
How notes carry over
The agent writes to _tfac/memory.md. Triage Factory saves those notes with the conversation and makes them available for later work.
- The next conversation gets the notes. Whether you requeue the task, hand it to a teammate, or assign another agent, the notes stay with it. The newest notes are included at the start of the next agent conversation.
- Later tasks for the same PR or issue get them too. If a PR's checks fail three days later, the agent handling the failure can read what was tried, what worked, and what the reviewer said.
- Interrupted runs can still leave notes. If a conversation stops or fails without a memory file, Triage Factory generates one from its transcript. The task shows a waiting state until the notes are ready for the next conversation.
example memory file
_tfac/memory.md
written by the agent before it finishes show hide
# Fix duplicate tasks after a poll retry ## What I did A retried poll could create two tasks for the same failed check. Updated task creation to reuse the existing active task. Added a test that sends the same event twice and checks that only one active task exists. The test passes locally. ## Why I changed it here The duplicate should be handled where tasks are created, because events can arrive from more than one source. Filtering only in the poller would leave other callers with the same problem. I kept both events in the log so we can still see the retry. ## What still needs checking - CI is still running. - Review the case where two pollers create the task at the same time. - Existing duplicate tasks are unchanged by this fix.
Each task has its own workspace.
Each task has its own copy of the repository. Conversations on that task run one at a time, so the next agent can use the files and notes left by the previous one.
Separate working files
Conversations on the same task use the same repository copy. Other tasks get their own copies, so agents working at the same time can edit files independently.
A fresh conversation
Each new conversation starts with the task details, docs, and saved notes. It does not inherit the previous agent's full conversation.
One conversation at a time
A task runs one conversation at a time. New events arrive as notes in the active conversation. The next conversation waits until the previous one's memory is ready.