DEV Community: Immanuel Gabriel

Temporal ranking finally gaining fruit.

Immanuel Gabriel — Sun, 21 Jun 2026 05:35:59 +0000

Immanuel Gabriel

Jun 20

I'm trying to teach my agents what "now" means. Here's how far I've gotten.

#ai #architecture #agents #webdev

4 min read

I'm trying to teach my agents what "now" means. Here's how far I've gotten.

Immanuel Gabriel — Sat, 20 Jun 2026 13:39:30 +0000

This is a builder's log, not a launch. I'm in the middle of a problem and I want to think out loud about it, because the people who replied to my last post moved my thinking more than a month of solo work did.

The moment it clicked

Last week Copilot told me a match scheduled for June 12 was still going to happen. Confident, future tense. I was reading it on June 20. The match was over.

The data wasn't wrong when it was retrieved. It went stale in the gap between retrieval and the moment it reached me, and nothing in the pipeline noticed. The agent had no sense of "now." It treated a fact from eight days ago exactly like a fact from eight seconds ago.

That's the thing I keep running into. We've taught agents to retrieve and to reason. We haven't taught them what time it is.

Background: what I've been building

I work on FreshContext, a judgment layer that sits between retrieval and reasoning. Any retriever (vector DB, web search, RAG, a tool call) hands it candidate context. It returns a verdict: use this, refresh it, verify it, exclude it, before the context reaches the model. It doesn't fetch anything itself. That boundary is on purpose, and it matters later in this post.

For a while the verdict included a safe_for_agent_handoff boolean. Felt solid. It wasn't.

The comment that broke my assumption

A commenter, ANP2 Network, made a point I couldn't argue with:

"An annotation, however structured, is something the next agent is trusted to respect. Infrastructure is something the next agent cannot route around without leaving a trace."

A boolean is a field on an object. Any step downstream can flip needs_verification into safe_to_cite and leave no fingerprint. A structured verdict raises the cost of ignoring it, but it doesn't make tampering visible. ANP2 was describing the same disease as the Copilot match, from the other end: a judgment that was true once and gets trusted forever, with nothing recording when it was made or whether it still holds.

Two symptoms, one illness. The verdict has no sense of time and no proof of origin.

Where I've landed (and the part I'm least sure about)

I weighed two fixes.

One: let the judgment layer itself become the verifier. Every pipeline routes through it for a yes or no.

Two: keep the layer pure. It produces a verdict, signs it (HMAC, secret stays server-side), and stamps evaluated_at so the verdict carries its own age. A thin wrapper around the agent checks the signature and enforces. Any downstream agent can hit a verify endpoint to confirm the verdict really came from the layer and the content hasn't changed.

I went with two. The reasoning: the second the judgment layer starts adjudicating instead of judging, it becomes a gatekeeper every pipeline has to pass through. Bigger attack surface, harder to adopt, and honestly a worse product. The no-fetch, no-enforce boundary is what lets other people drop this into their own stack instead of handing control to mine.

Against the two failures that started this:

The silent flip: rewriting the verdict breaks the signature. Verify says no. The omission stops being invisible.
The stale match: evaluated_at means the verdict knows how old it is. A downstream step can refuse a verdict that's aged out instead of trusting it on faith.
And the multi-agent case (someone raised this directly under the last post): Agent B stops trusting a verdict just because Agent A handed it over. B verifies the signature. One agent faking a score doesn't infect the next.

Here's what I'm still not sure about, and where I'd want a sharper eye than mine:

The wrapper is opt-in. Skip it and you're back to advisory. Is "provable, enforced only if you choose to" real enforcement, or annotation with a receipt?
Stateless verify is a network call at every real decision point. Cheap, not free. Where's the line where the latency isn't worth it?
Signing proves origin and integrity. It doesn't prove the verdict was right. A perfectly signed bad judgment is still bad. Am I solving the trust problem or just moving it somewhere quieter?

If you want to look

It's running. I'd rather you test it than believe me.

Run locally: npx -y freshcontext-mcp@latest
Live MCP endpoint: https://freshcontext-mcp.gimmanuel73.workers.dev/mcp
The full approach, the boundary, and what's live vs roadmap: https://freshcontext-site.pages.dev/context-integrity
Source and the verdict shape: https://github.com/PrinceGabriel-lgtm/freshcontext-mcp

Throw stale context at it. Try to make it bless something old. Tell me where it falls over.

Credit where it's due

ANP2 Network's comment is the reason this post exists. A good critique from a stranger is worth more than agreement from a hundred. If you've pushed on this in the threads and I haven't named you here, that's an oversight, not a snub, say so and I'll fix it. I read everything.

I'm building this from Grootfontein, Namibia, solo. Thinking in public is the only way I've found to think well. So: tell me where I'm wrong.

FreshContext in agent workflows: judgment at the context handoff

Immanuel Gabriel — Tue, 09 Jun 2026 05:23:27 +0000

FreshContext in agent workflows: judgment at the context handoff

After sharing FreshContext publicly, a few comments helped me sharpen where it fits.

One person asked whether I had tested it on larger datasets or production workloads.

Another pointed out something important about ingestion: if a table loses its headers, or a clause gets split in the wrong place, the context is already damaged before any judgment layer sees it.

That gave me a better way to think about the product boundary.

FreshContext is useful at the context handoff.

The simple shape is still:

```txt id="gpav98"
candidate context in
decision-ready context out




A caller provides candidate context. FreshContext evaluates it using signals like freshness, provenance, confidence, utility, and source profile. Then it returns a decision about how that context should be treated.

Examples:



```txt id="tvgx8u"
cite this
verify this
refresh this
use as background
watch this
exclude this

That is the part I want to keep clear.

The handoff problem

Agent workflows pass context around.

A retrieval step finds sources.
A planning step uses them.
A writing step turns them into text.
A review step checks the result.

Somewhere in that chain, source quality can disappear.

A source may begin as “relevant, but needs verification.”

After one summary, that warning is gone.

The next agent receives a clean paragraph and treats it as reliable.

That is the kind of problem FreshContext is trying to reduce.

The point is not to make the system more complicated. The point is to keep useful context judgment attached before another step uses it.

A simple flow could look like this:

```txt id="ly3xqz"
retrieval
-> candidate context
-> FreshContext judgment
-> agent reasoning




For larger workflows, the same idea can sit between agents:



```txt id="csh0xg"
research agent
-> FreshContext judgment
-> planning agent
-> writing agent
-> review agent

Not every step needs a judgment call. Some handoffs are low risk.

The useful question is:

```txt id="olec7s"
Before this context moves forward, do we know how much trust to place in it?




## Retrieval gives candidates. Judgment gives treatment.

Retrieval answers:



```txt id="pc4tou"
What might be relevant?

FreshContext asks:

```txt id="8tpxx7"
How should this context be treated?




A relevant source can still be stale.

A recent source can still be weak.

A useful source may only be good as background.

An official page may still need a date check.

A forum post may be useful signal, not proof.

This is why the output should be more than a relevance score.

A score can rank context.

A decision can guide the next step.

For example:



```txt id="50kg3l"
Decision: needs_verification
Reason: Relevant, but provenance is weak and the source date is unclear.
Action: Do not cite as primary until checked.

That kind of output is more useful to an agent than raw text alone.

Ingestion still matters

One community comment made this point well: judgment works better when ingestion preserves structure.

That means keeping things like:

```txt id="q0xnnt"
table headers
page numbers
section titles
source URLs
timestamps
author names
schema context
document boundaries




If that structure gets stripped away, FreshContext can still flag uncertainty, but it has less to work with.

A better pipeline is:



```txt id="t688h7"
structure-preserving ingest
-> context judgment
-> reasoning

That is a useful architecture because each layer has a job.

Ingestion keeps the source material intact.

FreshContext judges the candidate context.

The model or agent reasons with cleaner input.

That is also why I am trying not to rush the product into every adjacent category at once. The current value is in the judgment step.

Multi-data systems need different judgment rules

This becomes more important when a system uses many kinds of data.

A real workflow might pull from:

```txt id="eo5rwl"
PDFs
web pages
research papers
support tickets
GitHub issues
database rows
official docs
forum posts
internal notes
market signals




These sources should not all be treated the same way.

A research paper does not decay like a job post.

A support ticket does not carry the same evidence weight as official documentation.

A database row may look precise, while still missing the surrounding schema or business meaning.

A forum post may show useful community signal, while still being weak evidence.

FreshContext uses source profiles to handle that difference.

The goal is simple: judge different source types with different expectations.

Examples:



```txt id="9cn6tr"
academic_research
official_docs
jobs_opportunities
market_finance
social_pulse

The user-facing output should stay plain.

The internal rules can become more specific over time.

Where this can grow

The current public version is early.

It has a working evaluate_context path, source profiles, decision outputs, demos, arXiv proof work, reference adapters, and trust gates.

That is enough to test the shape of the idea.

It is not enough to claim large-scale production validation.

The next useful tests are practical:

```txt id="3prv3t"
larger candidate-context batches
more source profiles
latency and throughput checks
multi-agent pilot workflows
ingestion quality signals
decision benchmark sets




I do not want to add features just to make the system look bigger.

The better question is:



```txt id="65iw2l"
Does the judgment improve the next step?

If yes, the engine deserves to grow.

If no, more surface area will not help.

The current product boundary

For now, I am keeping the boundary simple.

FreshContext receives candidate context.

It evaluates the context.

It returns a decision-ready output.

That makes it useful as a checkpoint in RAG systems, agent workflows, and multi-data pipelines.

The most relevant use case I see right now is this:

```txt id="3kg0wn"
Keep agents honest about the sources they pass to each other.




If one agent hands context to another, the receiving agent should know whether that context is fresh, provenanced, citation-grade, uncertain, background-only, or in need of verification.

That is the job FreshContext is built around.



```txt id="xsbzp8"
candidate context in
decision-ready context out

That is the product identity I am keeping.

Why RAG needs context judgment, not just better retrieval

Immanuel Gabriel — Sun, 07 Jun 2026 09:25:14 +0000

Why RAG needs context judgment, not just better retrieval

Most RAG systems optimize for retrieval.

That makes sense.

Search better.
Embed better.
Chunk better.
Rank better.
Fetch more sources.

All of that matters.

But retrieval alone does not answer a different question:

Should this context actually influence the model?

That is the problem FreshContext is built around.

FreshContext is context judgment infrastructure for AI agents, RAG systems, and retrieval workflows.

The simple version:

candidate context in
decision-ready context out

Retrieval is not judgment

A retriever usually answers:

What might be relevant?

A context judgment layer asks:

What should happen to this context before it reaches the model?

Those are different problems.

A source can be relevant but stale.

A source can be recent but low-confidence.

A source can be useful as background but not strong enough to cite.

A source can have no reliable date.

A source can be a duplicate.

A source can need verification before it should influence an answer.

A normal RAG pipeline can retrieve all of that and still pass it straight into the prompt.

That is where things get messy.

The model may reason fluently from weak context, and the final answer can look confident even when the input material was stale, uncertain, or not citation-grade.

The missing layer between retrieval and reasoning

FreshContext sits after retrieval and before reasoning.

It does not try to replace search, vector databases, RAG frameworks, or agent frameworks.

It focuses on the boundary between them and the model.

The product spine looks like this:

candidate context
-> FreshContext Core
-> freshness / provenance / confidence / utility / source profile
-> decision helper
-> decision-ready output
-> model / agent / app

The goal is not just to produce another score.

The goal is to turn candidate context into a decision.

Example decisions include:

cite_as_primary
cite_as_supporting
use_as_background
needs_refresh
needs_verification
watch_only
exclude

That output is much more useful than only saying:

relevance: 0.84

Relevance is only one part of the story.

Freshness is not truth

One important boundary:

FreshContext does not claim that freshness equals truth.

A fresh source can be wrong.

An old source can still be valid.

An undated source can be risky.

A historical source may be useful, but not for a current claim.

So freshness should not be treated as a magic truth signal.

It should be one part of a broader context judgment process.

FreshContext evaluates candidate context with signals like:

source
published time
retrieved time
source type
semantic score
source profile
freshness
provenance
confidence
utility

Then it helps decide whether the source should be used, cited, refreshed, verified, backgrounded, watched, or excluded.

Source profiles matter

Different kinds of context decay differently.

A job post does not behave like a research paper.

A finance signal does not behave like official documentation.

A social pulse signal does not behave like an academic citation.

That is why FreshContext uses Source Profiles.

Examples:

academic_research
jobs_opportunities
market_finance
official_docs
social_pulse

The profile helps define how the system should treat freshness, confidence, provenance, and risk for that kind of source.

This keeps the interface simple while allowing the internal judgment to be more specific.

The current front door: evaluate_context

The current practical front door is:

evaluate_context

The caller brings candidate context.

FreshContext evaluates it.

That boundary is intentional.

evaluate_context does not fetch, crawl, browse, scrape, read folders, or retrieve by itself.

It evaluates caller-provided candidate context and returns decision-ready output.

A simplified input shape looks like this:

{
  "profile": "academic_research",
  "intent": "citation_check",
  "signals": [
    {
      "title": "Example source",
      "content": "Candidate context text...",
      "source": "https://example.com",
      "source_type": "official_docs",
      "published_at": "2026-06-01T00:00:00Z",
      "retrieved_at": "2026-06-07T00:00:00Z",
      "semantic_score": 0.92
    }
  ]
}

The important part is the output.

Instead of only returning raw retrieved material, FreshContext can return something closer to:

Decision: cite_as_supporting
Meaning: Useful supporting context, but not the primary source.
Action: Use with citation and keep stronger sources ahead of it.
Warnings: Date confidence is limited.
Why: Relevant, recent enough, but weaker provenance than official documentation.

That is the layer I think RAG and agent systems need more of.

Reference adapters are not the product

FreshContext includes reference adapters and proof surfaces.

Those matter.

But they are not the product identity.

The product is not “a pile of tools.”

The product is the judgment layer.

The stronger framing is:

FreshContext decides what context deserves to reach the model.

That is the category I am trying to clarify.

Why this matters for agents

Agents often pass information between steps.

One step retrieves.

Another summarizes.

Another decides.

Another writes.

Another acts.

If weak context enters early, the error can travel through the whole chain.

A context judgment layer gives the system a checkpoint before the next reasoning step.

It asks:

Should this be cited?
Should this be refreshed?
Should this be verified?
Should this only be background?
Should this be excluded?
Is the date reliable?
Is the provenance strong enough?
Is the source useful for this specific intent?

That is different from retrieval.

And it is different from final-answer evaluation.

It is judgment over the context before reasoning happens.

What is live now

FreshContext currently includes:

evaluate_context as the generic front door
Source Profiles
Core evaluation pipeline
Decision Helper
freshness, provenance, confidence, and utility evaluation
BYOC demos
arXiv signal-to-decision proof
trust/release gates
reference adapters as proof surfaces
public website
npm package

The simple use case is:

Bring candidate context.
Apply a source profile.
Evaluate the signals.
Return decision-ready context.
Let the model reason with cleaner input.

Product Hunt launch

FreshContext is scheduled for Product Hunt on Monday, June 8.

Product Hunt:
https://www.producthunt.com/products/freshcontext?launch=freshcontext

Website:
https://freshcontext-site.pages.dev/

GitHub:
https://github.com/PrinceGabriel-lgtm/freshcontext-mcp

npm:
https://www.npmjs.com/package/freshcontext-mcp

Final thought

RAG does not only need better retrieval.

It needs a stronger boundary between retrieval and reasoning.

That boundary should not blindly pass everything forward.

It should judge the context first.

FreshContext is my attempt to make that layer explicit, testable, and useful.

candidate context in
decision-ready context out

FreshContext decides what context deserves to reach the model.

FreshContext is becoming a context judgment layer, not a toolbox

Immanuel Gabriel — Tue, 02 Jun 2026 11:14:19 +0000

A few weeks ago, FreshContext was easy to describe badly.

I could say:

FreshContext is an MCP server with 21 tools.

That was technically true.

It was also the wrong headline.

The more I kept building, testing, and trying to explain it to people, the more obvious the problem became: nobody really cares that a project has “21 tools” unless they already understand what those tools solve.

A user does not wake up thinking:

I need 21 MCP tools.

They think:

Can I trust this source?
Is this information still current?
Is this thing worth citing?
Is this job still fresh?
Is this package active or abandoned?
Is this study useful, or just old background?
Which context should my agent read first?

That is the product.

Not the tool count.

Here is the short visual explainer:

https://youtu.be/Z41tnZ8BXu8

The old framing

The old FreshContext shape was:

21 MCP tools
→ fetch different kinds of information
→ stamp freshness metadata
→ return ranked context

Useful, but too implementation-shaped.

It made FreshContext sound like a plugin pack.

That creates the wrong questions:

Which tool do I use?
Why 21?
Do I need all of them?
Is this only for Claude?
Is this only MCP?

Those questions are a smell.

FreshContext should not be understood as a bag of tools. The tools are reference adapters. They prove the engine can handle different information classes: GitHub activity, social signals, academic papers, finance data, jobs, government records, company intelligence, and composite landscapes.

But they are not the product identity.

The new framing

FreshContext is becoming a context judgment layer.

The cleaner sentence is:

FreshContext turns raw retrieved information into freshness-ranked, explained, provenance-aware context.

The sharper sentence is:

FreshContext tells you whether a source deserves to be used, cited, refreshed, or ignored.

That is the actual lane.

The current architecture is moving toward this shape:

Raw candidate context
  → Source Profile
  → Core evaluation
  → ranked explanation
  → decision-ready context

The key phrase is decision-ready.

A raw score is not enough.

If FreshContext says:

Freshness: 16
Final score: 0.664
Utility: 14.006
Confidence: high

a normal person can fairly ask:

So what?

That is the next layer I am working toward.

The output should become more like:

Decision: Use as background
Meaning: This source is relevant and credible, but older than newer work.
Action: Use it for foundation, not as the latest evidence.

That is what makes it useful outside developer circles.

Source Profiles

The first step was separating source types from tools.

Different information ages differently.

A stock quote can go stale in hours.
A social launch signal can go stale in days.
A job listing can expire quickly.
An academic paper can remain useful for years.
Official documentation can be older than a blog post and still be more authoritative.

So FreshContext now has the idea of Source Profiles.

Examples:

official_docs
code_activity
social_pulse
academic_research
market_finance
jobs_opportunities
government_regulatory
company_intel
composite_landscape
local_custom

A Source Profile describes how a class of information should age, fail, rank, and explain.

That means the question is no longer:

Which of the 21 tools did this come from?

The question becomes:

What kind of source is this, and how should FreshContext judge it?

That is a better abstraction.

The first visible demo

There is now a local demo command:

npm run demo:evaluate

It takes hardcoded academic-style candidate sources and evaluates them through an academic research profile.

The current flow is:

raw candidate context
→ source profile policy
→ Core evaluation
→ ranked output

The demo shows a few important behaviors:

a fresh, relevant academic source ranks first
an older but still useful source remains usable
a missing-date source is warned
a failed or blocked source does not get treated as fresh

That last part matters.

A bad signal should not be dressed up as good context just because an agent needs an answer.

FreshContext is trying to be honest about uncertainty.

What this is not

FreshContext is not trying to become a legal advisor, medical advisor, tax advisor, or investment advisor.

That is not the promise.

The promise is smaller and more useful:

This source is current.
This source is stale.
This source is traceable.
This source has missing dates.
This source looks failed.
This source is worth reading first.
This source should be used only as background.
This source should be refreshed before being trusted.

That is citation and context judgment.

For example, in a research workflow, FreshContext should not say:

This medical conclusion is correct.

It should say:

This study may be relevant, but verify it against recent reviews, guidelines, and stronger evidence before relying on it.

That boundary matters.

Why this matters for agents

Most AI systems are limited by the quality of the context they receive.

If an agent receives stale, failed, irrelevant, or weakly sourced material, it can reason confidently from bad input.

FreshContext is meant to sit before that step.

retrieval results
tool outputs
notes
papers
docs
logs
links
        ↓
FreshContext
        ↓
ranked, explained, citation-ready context
        ↓
agent or human

This is why I am moving away from “tools marketing.”

MCP remains important. REST matters. SDK and CLI paths matter too.

But those are surfaces.

The center is Core.

Where this is going

The next layer is a decision layer.

Source Profiles answer:

What kind of source is this?

Intent Profiles will answer:

What is the user trying to decide?

A student asks:

Can I cite this?
Is this study still useful?
Is it background or current evidence?

A developer asks:

Is this package active?
Is the community responding well?
Is it worth testing?

A job hunter asks:

Is this job fresh?
Does it fit me?
Can I still apply?

A business user asks:

Is this market signal recent?
Is adoption visible?
Is this hype or substance?

Same Core.

Different intent.

The output should eventually become:

Decision: Cite as supporting
Decision: Use first
Decision: Needs verification
Decision: Refresh before using
Decision: Exclude

That is the practical layer.

The bigger shift

FreshContext started as an MCP project.

It is becoming a context infrastructure project.

The 21 tools are still useful, but they are no longer the headline.

They are proof surfaces.

The more durable product is:

standard input
standard evidence envelope
standard source profiles
standard decision labels
standard reasons and warnings

That can plug into agents, research workflows, student study tools, developer tooling, business analysis, and eventually larger systems that need context integrity before reasoning.

Current status

The latest clean milestone:

Core evaluation pipeline: working
Source Profile presets: working
Local REST handler: working
Local demo: working
MCP tools: still live
Worker runtime: untouched
No REST deployment yet
No npm publish change yet

The project is still early.

But the direction is clearer now:

FreshContext decides what context deserves to reach the model.

That is the product I am building toward.

Making Ops Pulse less project-specific and more useful for Cloudflare builders

Immanuel Gabriel — Tue, 19 May 2026 16:04:16 +0000

I built Ops Pulse because I needed a calmer way to diagnose my Cloudflare setup.

When you are running Workers, D1, cron schedules, and logs across a few small services, the hard part is not always “getting metrics.”

The hard part is knowing what the metrics mean.

A Worker can look scary because an old error is still inside a long report window.

A cron job can look broken when it simply was not expected to run yet.

A service can be idle without being unhealthy.

A feed can be healthy but quiet.

And sometimes the thing you are about to edit is not the thing that is actually failing.

That is the loop Ops Pulse is meant to reduce.

Cloudflare metrics in.
Plain-English diagnosis out.

What Ops Pulse does

Ops Pulse is a local-first CLI for diagnosing Cloudflare Workers, D1, cron schedules, and Workers Observability logs.

It runs on your machine, uses your own Cloudflare token, and produces readable reports about what looks healthy, degraded, idle, noisy, or unknown.

You can run it with npx:

npx freshcontext-ops-pulse --help

Or install it globally:

npm install -g freshcontext-ops-pulse
freshops --help

The tool is designed for people who want a quick operational read before they start changing code.

It can help inspect things like:

Worker request counts
error rates
invocation status
runtime exceptions
client disconnects
CPU and wall time
subrequests
D1 reads and writes
D1 latency
cron behavior
Workers Observability events
recent logs for a specific Worker
plain-English recommendations

Example commands:

freshcontext-ops-pulse report --hours 1
freshcontext-ops-pulse report --hours 6
freshcontext-ops-pulse logs --worker my-worker --hours 1
freshcontext-ops-pulse errors --worker my-worker --hours 24
freshcontext-ops-pulse assays

The goal is not to replace Cloudflare Observability.

The goal is to sit one layer above the raw signals and help answer:

What is actually broken?
What is healthy?
What is idle?
What is old noise?
What should I inspect first?
What should I avoid touching?

That last question matters a lot.

A surprising amount of debugging time is wasted changing healthy systems.

Local-first setup

Ops Pulse does not require a hosted dashboard.

It does not require an account with FreshContext.

It does not send your Cloudflare metrics to my server.

It reads from Cloudflare using the credentials you provide locally.

Required environment variables:

CLOUDFLARE_ACCOUNT_ID=
CLOUDFLARE_API_TOKEN=

The token should be read-only where possible.

The current docs explain recommended Cloudflare token permissions, but the basic principle is simple: only give Ops Pulse access to the Cloudflare resources you want it to inspect.

For example, if you only want it to inspect Worker analytics and logs, scope the token around that.

If you want it to inspect D1-related signals, include the relevant D1 read permissions.

Do not commit your .env.

Do not paste your token into issues, chats, or support threads.

That privacy boundary is now documented more clearly in PRIVACY.md.

Diagnostic assays

I also cleaned up the diagnostic assay documentation.

An assay is just a focused check that asks one operational question.

For example:

Do public/runtime versions agree?
Do MCP clients see the expected tools?
Is cache behavior visible enough to trust?
Was cron expected in this time window?
Is the Worker actually throwing runtime errors?

Each assay should return a simple shape:

status
reason
evidence
recommendation

The statuses are intentionally boring:

healthy
warning
degraded
unknown

The unknown state is important.

A diagnosis tool should not fake certainty.

If Ops Pulse cannot see enough evidence, it should say that clearly instead of pretending everything is fine.

For example, a cache correctness check should not claim the cache is healthy if cache metadata is not visible in logs. It should explain what is missing and what visibility would be needed to make the call.

That is the kind of behavior I want from the tool generally.

Not dramatic.

Not magical.

Just honest.

What changed in this patch

This was a documentation and onboarding patch, not a feature rewrite.

The latest cleanup added or improved:

a clearer README
generic setup for non-FreshContext users
better quickstart examples
environment variable guidance
recommended token-permission notes
PRIVACY.md
docs/ASSAYS.md
safer .env.example comments
clearer CLI help text

The README now frames Ops Pulse as a local Cloudflare diagnosis CLI first.

My own systems are just the first place I used it seriously.

That matters because the tool should be useful to someone running their own Worker, API, cron job, D1-backed app, feed service, or MCP server.

Who this is for

Ops Pulse is probably useful if you are:

running Cloudflare Workers
using D1
relying on cron schedules
checking Workers Observability logs
maintaining a small API or feed
building an MCP server on Cloudflare
debugging alone without a full observability stack
trying to tell fresh failures from stale noise

It is especially useful when you want a quick answer before touching code.

Sometimes the right answer is:

Do not edit this Worker.
The errors are old.
Cron was not expected in this window.
This other service is the one to inspect.

That kind of answer can save more time than another graph.

What it is not

Ops Pulse is not auto-remediation.

It does not patch your Workers.

It does not deploy anything.

It does not mutate Cloudflare resources.

It does not replace Cloudflare’s own dashboards.

It is also not trying to be a full observability platform.

The current version is intentionally small:

local CLI
read-only diagnosis
plain-English reports

That is enough for now.

Current status

Ops Pulse is live on npm.

It has crossed a small first signal of interest, with a little over 100 npm downloads at the time I checked.

That is not product-market fit.

But it is enough of a signal to keep polishing the setup, docs, and diagnosis flow.

npm:

https://www.npmjs.com/package/freshcontext-ops-pulse

GitHub:

https://github.com/PrinceGabriel-lgtm/freshcontext-ops-pulse

Try it:

npx freshcontext-ops-pulse --help

Or:

npm install -g freshcontext-ops-pulse
freshops --help

The next useful work is probably still small:

better markdown/json output
clearer resource selection
more diagnostic assays
more sample reports
a simple setup check
stronger examples for non-FreshContext projects

I am trying to keep the direction simple:

Cloudflare metrics in.
Plain-English diagnosis out.

If Ops Pulse helps one other builder avoid chasing stale noise or editing the wrong service, that is already useful.

The part after shipping an MCP server: making it fail honestly

Immanuel Gabriel — Wed, 13 May 2026 11:25:06 +0000

I thought the hard part was shipping the MCP server.

It was not.

The hard part started after the server was public, listed, installable, and testable outside my own machine.

FreshContext is my MCP project around freshness-aware retrieval. The basic idea is simple: agents should not treat stale information as current truth. Every retrieved signal gets wrapped with source, timestamp, retrieval time, and confidence metadata, then ranked with freshness decay before it reaches the model.

That was the first public story.

But once the site, npm package, MCP Registry entry, Agentic Market listing, and feed APIs were live, a different kind of work became more important:

Making the system fail honestly.

The bug that bothered me most

A read-only QA pass found several issues.

Some were normal integration problems:

one finance path was failing against Yahoo with a 401
the Hacker News tool rejected plain text even though the product copy implied search-like behavior
one HN scrape path produced a malformed timestamp
the local stdio package reported an old internal version

Annoying, but fixable.

The serious issue was different.

A failed finance call could still be wrapped as high-confidence output.

That is poisonous for a product about freshness and retrieval trust.

If a tool fails, it should not come back dressed as:

Confidence: high
Score: 100/100

That is worse than an obvious crash. A crash tells you something broke. A confident bad envelope quietly teaches the user to distrust the whole system.

So the next release was not about adding features.

It was about making failures honest.

The 0.3.17 release

The 0.3.17 patch focused only on validated problems.

No new verticals. No redesign. No “while we are here” expansion.

The finance adapter moved away from the broken Yahoo path and now uses Stooq as a no-key quote source.

Failure-looking adapter output is blocked from becoming high-confidence FreshContext output.

The Hacker News tool now accepts both URLs and plain text queries while keeping the same field name for compatibility.

HN dates are normalized before freshness scoring.

The Worker version, npm package, stdio server info, and MCP Registry metadata were aligned to 0.3.17.

I also added a small stdio smoke test so the package can prove the basics before release:

initialize works
server version matches package version
tools/list returns 21 tools
key tools exist

None of this is glamorous.

It is the maintenance layer that makes the public product feel less fragile.

The release gate became boring on purpose

The release flow became:

build locally
smoke stdio
check Worker TypeScript
deploy Worker
smoke live MCP endpoint
verify npm registry install
update public metadata

That order matters.

I did not want to publish npm and then discover that the deployed Worker path behaved differently. I also did not want the registry, npm package, and website telling three different stories.

The rule became:

Do not publish or update public surfaces until the live path works.

This is obvious in hindsight.

It is also exactly the kind of obvious thing that gets skipped when you are moving fast.

Why I built Ops Pulse

Around the same time, I built a small tool called FreshContext Ops Pulse.

It is not a dashboard. It is not a giant observability product. It is a local-first TypeScript CLI that reads Cloudflare metrics and turns them into plain-English diagnosis.

FreshContext runs across Cloudflare Workers, D1, cron, and a few small feed services.

That creates a practical debugging problem.

If the Fresh HN Feed is healthy, I should not touch it while debugging the MCP worker.

If the Jobs Feed is idle because no cron was expected in that window, that is not an outage.

If the MCP core has runtime exceptions, I need to focus there instead of randomly changing healthy systems.

Ops Pulse gives me that separation.

The pipeline is simple:

Cloudflare metrics -> normalized snapshot -> diagnosis -> recommendation

That helped shift the project from “poke around until something changes” to “debug from evidence.”

That is a major relief when you are solo-building and every fix can accidentally create two more bugs.

The real lesson

The biggest lesson was not about MCP specifically.

It was about consistency.

If the website says 21 tools, the registry should say 21 tools.

If npm says 0.3.17, the Worker should report 0.3.17.

If a source has a timestamp, normalize it before scoring.

If a tool fails, make the failure visible.

If one service is healthy, do not disturb it while fixing another service.

This sounds boring because it is boring.

But boring is what makes a tool usable.

A lot of early product work feels like building features. Then the product becomes public and the work changes. Suddenly the important thing is not “can I add one more thing?”

It is:

Can I trust the thing that already shipped?

For FreshContext, that meant stopping feature work for a moment and stabilizing the public surface:

MCP Worker live
npm package verified
MCP Registry updated
Agentic Market listing accepted
Fresh HN Feed live
Fresh Jobs Feed live
Apify actors published
Ops Pulse available for operational diagnosis

There is still plenty to improve.

But the project is now past the “just an idea” phase. It has install paths, public listings, live feeds, and a small ops loop watching the system.

That feels like a better foundation than another rushed feature.

Links

FreshContext hub:

https://freshcontext-site.pages.dev/

Live demo:

https://freshcontext-mcp.gimmanuel73.workers.dev/demo

MCP endpoint:

https://freshcontext-mcp.gimmanuel73.workers.dev/mcp

GitHub:

https://github.com/PrinceGabriel-lgtm/freshcontext-mcp

Agentic Market:

https://agenticmarket.dev/princegabriel73/server

The next step is not more feature sprawl.

It is better distribution, evidence-led debugging, and watching which surfaces people actually use.

I’m also testing a few FreshContext reviews this week. If you’re shipping an AI tool, MCP server, repo, launch page, or retrieval workflow, I can check for stale-context risk, broken public surfaces, weak provenance, version mismatches, and failure states that look too confident.

Email: gimmanuel73@gmail.com

Building FreshContext: Temporal Intelligence Infrastructure for AI Systems

Immanuel Gabriel — Mon, 11 May 2026 20:59:57 +0000

I’ve been building something called FreshContext.

The core idea is simple:

AI systems often treat fresh and stale retrieved information as equally useful.

FreshContext is an attempt to fix that.

Instead of only retrieving information, the system applies temporal scoring before signals reach an LLM or agent workflow.

That means:

source timestamps matter
decay matters
provenance matters
retrieval timing matters

What I built so far

1. FreshContext MCP

A Cloudflare-native MCP server with 21 tools focused on freshness-aware retrieval and live intelligence workflows.

Current stack:

Cloudflare Workers
D1
KV
structured JSON envelopes
freshness scoring
observability tooling

GitHub:
https://github.com/PrinceGabriel-lgtm/freshcontext-mcp

2. Fresh HN Feed

A freshness-ranked Hacker News signal feed.

Instead of simply listing posts chronologically, the feed scores signals using temporal decay and relevance weighting.

GitHub:
https://github.com/PrinceGabriel-lgtm/fresh-hn-feed

3. Fresh Jobs Feed

A freshness-ranked jobs API built on public job sources.

The current focus is AI/ML-oriented roles, but the architecture is designed for broader signal ingestion later.

GitHub:
https://github.com/PrinceGabriel-lgtm/fresh-jobs-feed

Live API:
https://fresh-jobs-feed.gimmanuel73.workers.dev

4. Ops Pulse

One thing I learned quickly:
observability matters.

I built a separate operational analysis tool for monitoring:

Workers
D1
cron ingestion
runtime failures
cache behavior
external API failures

The biggest improvement so far wasn’t a new feature.

It was finally seeing the actual failure patterns clearly.

What surprised me

The hardest part wasn’t generating responses.

It was:

freshness correctness
runtime isolation
cache correctness
partial failure handling
observability
temporal consistency

The infrastructure side of AI systems is much deeper than I expected.

Current direction

The long-term goal is turning FreshContext into a broader temporal intelligence platform:

freshness-aware feeds
agent retrieval infrastructure
signal marketplaces
operational intelligence
temporal ranking APIs

Still very early.
But the architecture is finally starting to stabilize.

If you’re building retrieval systems, agents, MCP tooling, or Cloudflare-native AI infrastructure, I’d genuinely love to connect and learn from others working in this space.

DEV Community: Immanuel Gabriel

Temporal ranking finally gaining fruit.

I'm trying to teach my agents what "now" means. Here's how far I've gotten.

I'm trying to teach my agents what "now" means. Here's how far I've gotten.

FreshContext in agent workflows: judgment at the context handoff

FreshContext in agent workflows: judgment at the context handoff

The handoff problem

Ingestion still matters

Multi-data systems need different judgment rules

Where this can grow

The current product boundary

Why RAG needs context judgment, not just better retrieval

Why RAG needs context judgment, not just better retrieval

Retrieval is not judgment

The missing layer between retrieval and reasoning

Freshness is not truth

Source profiles matter

The current front door: evaluate_context

Reference adapters are not the product

Why this matters for agents

What is live now

Product Hunt launch

Final thought

FreshContext is becoming a context judgment layer, not a toolbox

The old framing

The new framing

Source Profiles

The first visible demo

What this is not

Why this matters for agents

Where this is going

The bigger shift

Current status

Making Ops Pulse less project-specific and more useful for Cloudflare builders

What Ops Pulse does

Local-first setup

Diagnostic assays

What changed in this patch

Who this is for

What it is not

Current status

Next

The part after shipping an MCP server: making it fail honestly

The bug that bothered me most

The 0.3.17 release

The release gate became boring on purpose

Why I built Ops Pulse

The real lesson

Links

Building FreshContext: Temporal Intelligence Infrastructure for AI Systems

What I built so far

1. FreshContext MCP

2. Fresh HN Feed

3. Fresh Jobs Feed

4. Ops Pulse

What surprised me

Current direction