Forem: Prodevel

I got tired of re-explaining my projects to Claude — so I built context-window

Promise — Sat, 16 May 2026 11:59:15 +0000

Every time I opened up a new Claude conversation, I find myself re-telling it the same things. Who I am. What stack this project uses and more importantly, for business context, I find myself resharing the same business rules. The two odd conventions we picked up six months ago. That one third-party API quirk that bit us last quarter.

It's not Claude's fault. It can't remember things across sessions — that's how the model works. But it means I'm doing the same warm-up exercise every single time. Multiply that by however many projects I touch in a week and it adds up to hours of wasted effort.

So I built a small tool to fix it for myself, and I've open-sourced it: context-window.

The idea

What if your context was a first-class entity, not something you re-type into a chat?

You write a context once — your coding conventions, your business background, notes on a tricky API. It lives in a local library with a name, a description, a category, tags, a priority, and a token count.
You attach it to as many projects as you like. The same "Rust Conventions" context can be referenced by every Rust repo on your machine.
Each project owns a tiny manifest file — just metadata, not the full bodies — that any LLM client can read at session start.
The LLM decides which contexts are relevant, asks for the bodies it actually needs, and gets to work already up to speed.

That's the whole shape of it. Two entities (Context and Project), one manifest, one MCP server, no cloud.

What it looks like in practice

Create a context once:

context new \
  -n "Rust Conventions" \
  -d "How we write Rust in this codebase" \
  --content-file ./RUST_STYLE.md \
  --category conventions \
  --tags rust,backend \
  --priority important

Then, from any project on your machine:

cd /path/to/your/project
context project init -n my-project
context project attach <context-id>

That writes a .context/manifest.json in the project root. It looks like this:

{
  "project_name": "my-project",
  "mcp_server": { "transport": "stdio", "command": "context-mcp" },
  "contexts": [
    {
      "context_id": "…",
      "name": "Rust Conventions",
      "description": "How we write Rust in this codebase",
      "category": "conventions",
      "priority": "important",
      "token_count": 1240
    }
  ],
  "total_token_count": 1240,
  "instructions": "Call get_project_summary first. Use get_context to fetch a body. ..."
}

Note the deliberate absence of content. The manifest is a catalogue — names, descriptions, categories, priorities, token counts. The LLM reads this on session start, decides what's relevant, and fetches bodies on demand via the MCP server. Cheap.

Wiring Claude up to it

context-window ships with a stdio MCP server (context-mcp). One command registers it globally with Claude Code:

claude mcp add context-window --scope user context-mcp

No --project-id is needed. The server walks up from the current working directory looking for the nearest .context/manifest.json and uses that project automatically. Move between repos, and the active project follows you.

There are 16 MCP tools, but in practice you only think about a handful:

get_project_summary — orient yourself; returns the manifest
get_context — fetch the body of one context
search_contexts — FTS5 search across the library
get_context_budget — when you're tight on tokens, ask for the highest-priority subset that fits a given budget
create_context / attach_context — capture and link new knowledge mid-conversation

The last point is the most underrated. When the user explains something, the next session will need to know — a constraint, a decision, a person's preference — the model can call create_context(..., created_by: "llm:claude-opus-4-7") and that knowledge is permanent and reusable. The conversation doesn't have to be wasted as soon as you close the tab.

What else did I like: usage analytics

I quickly realised I wanted to know if Claude was actually using the contexts I was carefully curating. So every MCP, CLI, and web call records an event with:

the tool name
duration, outcome, error code
the active project and (when applicable) the context id touched
the calling client's name and version — claude-code, chrome, cli, firefox, etc.

That last one matters. The MCP server captures the clientInfo block from the initialize handshake, so the dashboard tells you exactly which client (and which version) is calling each tool. If Claude Code is doing the work, you'll see claude-code in the breakdown. If you use the web UI yourself, you'll see your browser. If you forget you wired up a different LLM, you'll see it sitting there in the bar chart.

The dashboard is server-rendered HTML with SVG charts. No client-side framework, no build step beyond tsc. There's a sparkline for activity over time, four bar charts (top tools, top contexts, top projects, top clients), and a row of summary stat cards. It runs at http://127.0.0.1:5173/dashboard after context web.

A few interesting design choices

The manifest is derived state. If you update a context that's attached to three projects, all three manifests rewrite themselves automatically. Same for archive, delete, attach, detach, reorder. There's exactly one source of truth — the SQLite DB — and the on-disk manifest is always a fresh projection of it. No staleness, no sync command needed.

Inactive contexts are hidden, not surgically removed. Archive a context and it stays attached to whatever projects already had it, but it's filtered out of get_project_summary, get_context_budget, and search_contexts. So an LLM never sees stale knowledge as "available", but the link is preserved if you decide to unarchive later.

Token counts are pre-computed on write. Every time a context is created or updated, we tokenise it with gpt-tokenizer and store the count. That means get_context_budget can do its work entirely as a SQL query — no expensive tokenisation per request.

Storage is transport-agnostic. The whole codebase is split into core/ (business logic), storage/ (the Repository interface + a SQLite implementation), and three transports (mcp/, cli/, web/). If someone wanted to add a Postgres backend or an HTTP MCP transport for a cloud mode, they'd swap the storage + add a transport. The core services don't move.

Try it

git clone https://github.com/prodevuk/context-window.git
cd context-window
npm install
npm run build
npm install -g .
context project init       # in your project
context web                # http://127.0.0.1:5173
claude mcp add context-window --scope user context-mcp

That's the whole getting-started. It's TypeScript, Node ≥ 20, SQLite. No accounts, no API keys, no telemetry, no network calls (unless you point an MCP client at it).

The repo has a 10-test unit suite plus end-to-end smoke tests against both the stdio MCP server and the web UI.

Where to take it from here

A few things on my list:

Better budget heuristics. Right now get_context_budget is a strict priority-then-position fit. It could be a lot smarter — maybe weight by recent usage from the analytics it already collects.
A proper "what should I capture next?" prompt for the LLM, surfaced as an MCP tool.
Per-project token windows that match the actual model's window, not a fixed default.
Encrypted-at-rest contexts for the ones marked visibility: private.

If you've ever felt the same pain — "I'm pasting the same paragraph again, aren't I?" — I'd love to hear what you'd want from a tool like this.

The repo is at github.com/prodevuk/context-window. Issues, ideas, and PRs are all very welcome. MIT licence.

Thanks for reading.

Toxic Relationships 💔: When Your Agents Hallucinate

Promise — Fri, 13 Feb 2026 11:25:39 +0000

Love is blind, but in production, blind trust is a fatal architectural flaw.

This Valentine’s Day, while others talk about chemistry, let’s talk about state divergence. The most toxic relationship in your stack is the one between an unmoderated Lead Agent and a specialised Worker. Without strict validation, your agents will start finishing each other's sentences in the worst way possible: by hallucinating context that doesn't exist.

Reliability in autonomous systems isn't about better prompting. It is about better boundaries. When you allow an agent to update your global state without a verification layer, you are essentially allowing a non-deterministic process to rewrite your source of truth.

The Actor-Critic Architecture

Instead of a linear chain of command, we deploy an Actor-Critic pattern. This separates the creative process of problem-solving from the rigid process of validation. The Actor proposes a solution, but the Critic, governed by a different set of constraints and tools, must sign off on the work before it is committed to the state.

The diagram below illustrates this relationship. Notice that the human is not a bottleneck for every task, but sits behind a high-integrity gate for critical actions.

graph TD
    A[User Request] --> B{Lead Orchestrator}
    B --> C[Actor Agent: Generation]
    C --> D[Proposed Action/Code]
    D --> E{Critic Agent: Validation}
    E -- Rejected: Hallucination Detected --> C
    E -- Approved: Schema Validated --> F[Human-in-the-Loop Gate]
    F -- Approved --> G[Production Execution]
    F -- Denied --> B
    G --> H[Update Global State]

Breaking the Feedback Loop

The danger of agentic relationships is the echo chamber effect. If an Actor Agent makes a mistake and the Orchestrator accepts it as fact, every subsequent step in the graph is built on a lie. We break this by ensuring the Critic has access to an independent source of truth, such as a read-only database or a static documentation repository, which the Actor cannot influence.

By the time the process reaches a Human-in-the-Loop gate, the "relationship" between the agents has already filtered out the noise. The human isn't there to fix basic logic errors. They are there to provide high-level strategic approval.

The Strategic Benefit

Moving from blind execution to Actor-Critic orchestration changes the ROI of your AI initiatives. You spend less time debugging erratic behaviour and more time scaling the system.

Reduced Token Waste: Catching errors early in the graph prevents expensive, long-running loops based on false premises.
Auditability: Every disagreement between the Actor and Critic is logged, providing a clear map of where your prompts or tools need refinement.
Governance: You can swap out the Actor for a cheaper model while keeping a high-frontier model as the Critic to maintain quality control.

Stop falling in love with your first prototype. Build an orchestration layer that challenges its own assumptions.

Would you like me to design a specific Critic schema for your most frequent agent failure modes?

Agentic Amnesia: The State Management Crisis

Promise — Sat, 07 Feb 2026 03:08:26 +0000

The most significant bottleneck in 2026 enterprise AI isn't model intelligence. It is memory.

We see it weekly at Prodevel. A firm deploys a sophisticated multi-agent system to handle supply chain logistics or legal discovery. For the first three steps, the system is brilliant. By step four, the agents begin to wander. By step six, they have forgotten the original constraint entirely. This is agentic amnesia: the catastrophic loss of context that occurs when an autonomous system fails to maintain a persistent, coherent state.

In the early days of 2024, we relied on long context windows to solve this. We simply stuffed the entire conversation history into the prompt. But in a production environment where agents interact with dozens of tools and generate thousands of tokens, "context stuffing" is both expensive and noisy. It leads to the lost-in-the-middle phenomenon, where the model ignores the very instructions that matter most.

The Architecture of Remembrance

To solve this, Prodevel has moved away from stateless chains. We treat agentic workflows as long-running processes that require a dedicated state backend. If your agent doesn't have a "checkpoint" system, it isn't an enterprise tool. It is a toy.

We utilize a state-first design pattern. Instead of passing a growing string of text between agents, we pass a pointer to a structured state object stored in a persistent layer like Redis or Postgres.

Check-pointing: Every time an agent calls a tool or makes a decision, the state is saved. If the execution environment crashes, the agent resumes from the last known good state rather than restarting the entire reasoning loop.
Thread Scoping: We decouple the short-term working memory (the current task) from the long-term archival memory (the project history).
State Summarisation: As the state grows, a background "Summariser Agent" compresses older interactions into high-signal metadata. This keeps the active context window lean and focused.

Technical Implementation: The Checkpointer Pattern

Here is how we implement persistent state management in a 2026 agentic graph using a TypeScript-based orchestration layer. This ensures that the agent retains its "identity" and progress across asynchronous tool calls.

import { StateGraph } from "@langchain/langgraph";
import { RedisSaver } from "@langchain/langgraph-checkpoint-redis";

// Define the schema for our persistent state
const StateSchema = {
  plan: { value: (x, y) => y, default: () => [] },
  completed_steps: { value: (x, y) => x.concat(y), default: () => [] },
  current_error_count: { value: (x, y) => y, default: () => 0 },
};

// Initialize the Redis-based checkpointer for 2026 production loads
const checkpointer = new RedisSaver({ 
  uri: process.env.REDIS_URL || "redis://localhost:6379" 
});

// Build the graph with a 'Thread ID' for persistence
const workflow = new StateGraph({ channels: StateSchema })
  .addNode("researcher", researchNode)
  .addNode("writer", writingNode)
  .addEdge("researcher", "writer");

// The 'thread_id' is the secret to curing amnesia
const app = workflow.compile({ checkpointer });

const config = { configurable: { thread_id: "project_finance_audit_001" } };
await app.invoke({ plan: ["Analyze Q4 data", "Check compliance"] }, config);

The Strategic Moat

Founders often ask why they should invest in custom orchestration rather than using a standard chat interface. The answer is reliability. A stateless agent is a liability because its failure mode is silent and unpredictable.

A state-managed system provides a full audit trail. You can see exactly where the logic diverged. You can rewind the state, fix the underlying tool or prompt, and re-run the execution from the point of failure. This isn't just better engineering. It is the only way to build a moat around your AI operations in 2026.

If your agents are currently wandering in circles, you don't have a model problem. You have a state problem.

Would you like me to review your current orchestration logic to identify where your state is leaking?

5 skills you need to develop as a recent Computer Science Graduate

Promise — Fri, 06 Feb 2026 16:23:09 +0000

The Post-Syntax Era: 5 Skills for the 2026 CS Graduate

Congratulations. You have graduated into the most volatile labour market in the history of computing.

In 2026, the industry has undergone a fundamental decoupling. Writing syntax is no longer the moat for a software engineer. LLMs and autonomous agents have commoditised boilerplate, unit testing, and even complex refactoring. If you enter the workforce expecting to be a coder, you are already obsolete.

At Prodevel, we look for systems architects in training. These are graduates who understand that software is now a collaborative dance between human intent and agentic execution. Here are the five non-negotiable skills you need to survive and thrive in 2026.

1. Agentic Orchestration and Graph Logic

By now, prompt engineering is a relic of 2024. Today, we build agentic workflows. You need to move beyond single-turn chats and learn to design multi-agent systems where specialised models, such as Architects, Coders, and Reviewers, collaborate within a state-controlled environment.

The Technical Shift: Mastering frameworks like LangGraph or PydanticAI to manage cycles and state.
Why it matters: You aren't writing the code. You are writing the logic that governs the agents writing the code.

2. Context Engineering and RAG 2.0

In 2026, the bottleneck isn't the model's parameters. It is the data you feed it. Retrieval-Augmented Generation (RAG) has evolved from simple vector searches into complex agentic RAG pipelines that utilise knowledge graphs and hybrid search.

The Skill: Understanding how to structure unstructured data, including PDFs, Slack logs, and Notion, into a format an LLM can actually reason over without hallucinating on outdated context.
Prodevel Insight: If you can't manage a vector database like Pinecone or Weaviate and optimise a retrieval pipeline, you are effectively flying blind.

3. Security-by-Design and Agentic Guardrails

With autonomous agents operating at scale, the attack surface has exploded. We have seen prompt injection evolve into agent hijacking, where malicious actors attempt to take control of an agent’s tool-calling capabilities.

The Requirement: You must understand the OWASP Top 10 for LLMs.
Implementation: Learning to deploy strict Human-in-the-Loop (HITL) gates and sandbox environments for agent-executed code. In 2026, a developer who ships an agent without execution guardrails is a liability.

4. Mathematical Foundations (The Deep T-Shape)

While tools change every six months, the math doesn't. To debug a model that is behaving erratically, you need to understand what is happening under the bonnet.

The Core: Linear algebra, probability, and transformer architecture.
The Value: When an agent gets stuck in a reasoning loop, a junior dev tries a different prompt. A Prodevel engineer analyses the attention mechanism or temperature settings to fix the root cause.

5. Multi-Cloud and Edge Deployment

The cloud is no longer just AWS or Azure. In 2026, we are deploying smaller, domain-specific models (SLMs) to the edge. This includes mobile devices, IoT, and local servers to reduce latency and cost.

The Toolset: Kubernetes, Docker, and WebAssembly (Wasm) for running high-performance AI logic in the browser or at the edge.
Strategic Advantage: Companies are desperate for engineers who can balance the intelligence-to-cost ratio by deciding when to use a frontier model versus a local, fine-tuned Llama-4 variant.

Tool Definition Logic

In 2026, we spend more time defining tools than functions. Here is how a Prodevel engineer defines a type-safe tool for an agent using TypeScript:

import { z } from "zod";

export const DatabaseQueryTool = {
  name: "query_production_db",
  description: "Executes read-only SQL queries. Requires Human-in-the-loop for DELETE/UPDATE.",
  schema: z.object({
    query: z.string().describe("The SQL query to execute"),
    limit: z.number().default(100),
  }),
  execute: async ({ query, limit }, context) => {
    const forbidden = ["DELETE", "DROP", "UPDATE", "TRUNCATE"];
    if (forbidden.some(word => query.toUpperCase().includes(word))) {
      throw new Error("Unauthorized: Destructive queries require manual sign-off via HITL-Gate.");
    }
    return await db.readOnlyPool.query(query, { limit });
  }
};

The Bottom Line

The 2026 Computer Science degree is a ticket to the stadium, not a seat in the VIP box. To stay relevant, you must pivot from being a builder of software to an orchestrator of intelligence.