The idea was small.
Coding agents should not have to rediscover the same infrastructure details, deployment procedures, architectural decisions and troubleshooting steps every time a new session begins. That knowledge should belong to the team, remain available across agent runtimes, and improve through continued use.
The internal system was the working implementation of that idea, built to support one engineering environment's daily AI-assisted development. Firekeep is its self-hosted, generalized evolution.
Nearly five months of daily use
The first commit landed on March 13, 2026. A snapshot taken August 9 shows what accumulated:
One team, one deployment, a dated snapshot — not a benchmark. The number worth noticing is the last one: memory was read and written in ordinary sessions as part of the work, not maintained as a separate documentation exercise.
The sessions were a mix of coding, deployment work, infrastructure diagnostics, documentation and operational troubleshooting. Agents recalled shared knowledge, recorded new discoveries, retrieved internal documents, and received relevant procedures at session start.
One incident, retold properly
During a deployment, an AI assistant stopped responding without producing a useful error. The root cause took real digging: Python was resolving through a symlinked release directory while the deployment pipeline copied only part of the required configuration into that release.
The eventual solution included a diagnostic technique worth keeping: reproduce the subprocess locally with a clean environment and a temporary home directory before debugging the larger system around it. That procedure was captured as a team skill — cause, reproduction process, fix, and a deployment-specific warning.
Weeks later, when work touched an adjacent area, the system surfaced that skill in the session's pre-flight briefing — before the agent had typed anything.
The value was not that the incident had been documented. Documentation existed before. The value was that the right knowledge returned at the moment it became relevant, to an agent that never saw the original incident.
An operational skill library, accumulated sideways
Over five months the team accumulated 45 active skill cards, none written as a documentation project — each captured at the moment something was solved:
- Deployment and release recovery
- Kubernetes namespace access
- Certificate imports
- Jira and agent-tool configuration
- DNS and LDAP diagnostics
- Kafka consumer troubleshooting
- CI/CD and artifact-management procedures
This is knowledge that normally lives in terminal history, chat transcripts, or one person's head. The internal teams run their sessions through Kiro — one runtime, standardized. The skills don't care: they are stored independently of any agent runtime, so the same procedures would serve Claude Code, Codex or OpenCode sessions unchanged the day anyone switches. That runtime independence became one of Firekeep's central design principles: the knowledge layer should outlive the tool that created it.
Two teams, one memory
Read that skill list again and notice the split. Deployment recovery, CI/CD, agent-tool configuration — development work. Kubernetes access, DNS and LDAP diagnostics, Kafka troubleshooting, certificate imports — operations work. The deployment served two groups whose knowledge usually lives in separate places, and the sharing was the point.
The development team worked the same project day after day, much of it vibe coding — and that style of work is exactly where session memory pays. Each session opened already briefed on yesterday's decisions, the conventions that had settled, and the playbooks matching the goal, so an agent picked up mid-thought instead of re-deriving the project from its file tree. The workflow compounded: what one session learned about the build, the deploy pipeline, or a subsystem's quirks was already in the next session's briefing.
The operations team inherited what development learned without anyone writing a handover. The knowledge a development session records while building a system — why a service is configured the way it is, which settings are load-bearing, how the last release recovery actually went — is exactly what an operations session needs when that same system misbehaves in production. Recall does not care which team wrote the memory; an operations agent diagnosing a failing service pulled up the development-era decisions behind it as naturally as its own runbooks.
The flow ran both ways. Incidents worked in operations became skills that development saw in pre-flight briefings when touching adjacent code — the deployment-specific warning from the incident above is one of them. Two teams, opposite ends of the software lifecycle, one memory between them.
Documents available inside the work
The team also ingested 12 internal documents — engineering runbooks, installation guides, architecture material, deployment documentation. Divided into searchable sections and stored alongside operational memories and skills, the relevant portion of a runbook surfaces during recall without anyone locating the original document, copying its contents, or explaining where it lives.
That put several kinds of organizational knowledge in one working environment: short operational memories, reusable procedures, long-form documents, session context and decisions. Documentation stopped being a destination an engineer had to remember to visit.
Self-hosted the whole time
The internal deployment runs on the team's own Rancher-managed Kubernetes cluster. Redis, Neo4j and Qdrant provide storage and retrieval; Ollama handles model inference locally, so the memory layer runs with no per-token API charges and nothing leaves infrastructure the team controls.
That constraint was kept deliberately and became a product principle: persistent agent memory can remain inside infrastructure owned by the organization using it.
From internal system to Firekeep
Firekeep takes the model that proved useful there and makes it portable: persistent team memory across sessions, reusable operational skills, searchable document ingestion, session continuity with pre-flight briefings, replayable agent activity, environment awareness, and support for multiple MCP-capable runtimes — self-hosted, as one product.
Firekeep does not replace the coding agent. It gives existing agents a shared memory and operational context they carry from one session to the next. That separation matters: teams can change models, agent clients, or development environments without abandoning the knowledge accumulated while using them.
Five months of daily use demonstrated the core claims on real work: a difficult deployment discovery returned during a later session, operational procedures became shared team assets, and internal documentation became available inside agent-assisted workflows. Firekeep is that experience generalized — not a speculative agent interface, but a system already used to preserve and retrieve real engineering knowledge, brought to teams outside the environment where it began.