Live context over static prompts
Operational truth changes too quickly to paste into a system prompt. Agents queried the same current state the product used.
← Work / SystemsThe system knows what happened.
Archived / Operator OS · personal experiment
The system knows what happened.
The agent can ask.
An archived private homelab experiment: a Go / Next.js monorepo of ~14 services with MCP over SSE, operator decision support, automated ingestion, and persistent state—previously operated for education, not offered as a public service or maintained as an active product.
// operating model
- ROLE
- Sole architect + operator
- STATE
- Archived / Retired
- AGENTS
- Tool-driven via MCP
- DELIVERY
- Private homelab
Archived project: I built and operated TechBearing in my private homelab. It’s now retired. What’s here is the architecture and what I learned from running it.
These figures describe the version covered in this case study. They aren’t live counters.
~14
long-running services
MCP
live agent interface
SSE
streaming transport
Solo
built + operated
01 — The problem
Operational knowledge kept evaporating.
Operational knowledge was scattered across infrastructure, repositories, telemetry, notes, and runbooks—and repeatedly lost between sessions. Operators and agents needed one durable, queryable view of what changed, what mattered, and what happened next. The answer was not another dashboard or chat window. It was a shared operating system where workflows, automations, people, and agents could work from the same live, durable context.
02 — Context pipeline
Sources01
System telemetry · repositories · deployment events · runbooks · operator input
Ingestion02
Automated pipelines normalized and refreshed operational context
State03
Persistent records kept history across sessions, restarts, and model changes
MCP04
Typed tools exposed current context over SSE so agents could ask for what they needed
Agents05
Assistant workflows used current data alongside stored history
03 — Engineering decisions
Design the intelligence around the system—not the demo.
Memory outside the model
Useful history belongs in durable application state—not inside a vendor session that can disappear or change shape.
MCP as a boundary
The agent interface was explicit and inspectable. The same tools could be used with different models.
Services around domains
Separate services let ingestion, system state, automation, and notifications evolve independently.
04 — What shipped
An operating system, not an AI wrapper.
- ▹MCP server (SSE transport) consumed by AI agents
- ▹AI decision-support workflows grounded in live operational data
- ▹Automated multi-source ingestion pipelines
- ▹Persistent-state architecture operated continuously in a private homelab
The numbers below are snapshots from this write-up. They aren’t updated automatically as the project changes.
Constraints / Evidence
The conditions shaped the system.
- ◆Private educational system: no public availability or implied customer deployment
- ◆I owned the architecture, delivery, observability, and recovery
- ◆Operational context changes continuously and cannot be frozen into prompts
- ◆Agent access must remain inspectable and independent of any single model vendor
~14
services
Roughly fourteen services in the system I operated before retiring it.
MCP/SSE
agent boundary
Tools gave agents access to current state while the system was running.
Durable
state model
Stored history carried across restarts, sessions, and model changes.
Archived
status
Retired personal experiment; retained as an architecture case study.
The result
Live operational context became a reusable capability—for dashboards, workflows, automation, runbooks, and agents.
Talk operator systems →