Live context over static prompts
Operational truth changes too quickly to paste into a system prompt. Agents query the same current state the product uses.
← Work / SystemsThe system knows what happened.
Operator OS · live context for humans and agents
The system knows what happened.
The agent can ask.
A private homelab portfolio project: a Go / Next.js monorepo of ~14 services with MCP over SSE, operator decision support, automated ingestion, and persistent state—operated continuously for education, not offered as a public service.
// operating model
- ROLE
- Sole architect + operator
- STATE
- Persistent + live
- AGENTS
- Tool-driven via MCP
- DELIVERY
- Private homelab
Deployment context: TechBearing is a private portfolio and educational system running in my homelab. “Production-mode” means it is continuously operated with persistent state, observability, delivery automation, and recovery practices. It does not mean public availability, a commercial SaaS offering, or a customer deployment.
~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 normalize and continuously refresh operational context
State03
Persistent records and memory survive sessions, restarts, and model boundaries
MCP04
A typed tool surface exposes live context over SSE instead of stuffing it into prompts
Agents05
Decision-support and assistant workflows reason over current data and durable 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 is explicit, inspectable, and reusable. Tools expose capabilities without coupling every workflow to one model.
Services around domains
The system separates operational domains so ingestion, system state, automation, and notifications can 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
Constraints / Evidence
The conditions shaped the system.
- ◆Private educational system: no public availability or implied customer deployment
- ◆One operator owns 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
Domain boundaries exercised as an operating system, not a slide.
MCP/SSE
agent boundary
Live tools expose current state without prompt stuffing.
Durable
state model
Operational history survives restarts, sessions, and model changes.
Private
deployment
Continuously operated in the homelab with production-mode practices.
The result
Live operational context became a reusable capability—for dashboards, workflows, automation, runbooks, and agents.
Talk operator systems →