The data plane for AI agents. It feeds them the right context, and triggers them when it changes.

Your agent's context is scattered across streams, files, and its own memory. NavFlow plugs into all of it, keeps it lossless, and serves it from one place over MCP: your agent pulls when it needs to, and gets triggered when something changes. One read path instead of a dozen.

Get startedSee how it works

Free tier · no credit card required

how it works

One project. Every source the agent needs, shaped and ready.

  1. 01Connect sources

    Streams (HTTP, OTLP, webhooks) or files (S3, GCS, exports). Same project, both lanes.

  2. 02Define a project

    Name it. List the sources. Set filters and retention. The project is what your agent will read.

  3. 03NavFlow stores and indexes

    Events normalized to one schema, windowed by key, indexed for query. Aggregations computed once when events arrive.

  4. 04Agent reads via MCP

    Pull on demand. Or set a trigger and NavFlow pushes when something matches.

navflow · project: checkout-agent
mcp://checkout-agent
Sources
github.pushstream
vercel.deploystream
stripe.webhookstream
otlp.spansstream
april_logs.csvfile
Stored
schemanormalized
windowtime-indexed
filterper-project
aggregations7
agent_memoryrun_8814
Agent reads
checkout_dropready
deploy_correlateready
recent_errorsready
last_run_memoready
served viamcp + webhook
model context protocol

Set it up over MCP. Read it over MCP.

The same MCP your assistant uses to configure a project is the protocol your agent uses to read from it. No second SDK to learn, no separate config API.

configure

Set up the project from your IDE. In English, if you want.

Ask Claude or Cursor to add a source, set a filter, define an aggregation. Every action in the NavFlow console is reachable as an MCP tool call — no separate config API.

# in your assistant, ask:
"Add github.push as a source to my agent_context project."
# the assistant calls:
navflow.add_source(
project="agent_context",
type="stream",
source="github.push",
filter="repo=production/*",
)
Claude Code · Claude Desktop · Cursor · any MCP-aware assistant
read

Read the project from your agent. At runtime, in production.

One MCP call returns events, history, aggregations, and agent-written memory in one normalized shape. No second SDK, no separate API.

# in your agent, at runtime:
ctx = await mcp.read(
"mcp://navflow/agent_context"
)
# returns:
{
"events": [...last 4h, normalized],
"last_4h": {aggregations},
"deploy_state": "v4.13",
}
LangChain · CrewAI · AutoGen · plain HTTP. Anything that speaks MCP.
same protocol surfaceOAuth or bearer tokenheadless-friendly for CI
push triggers

MCP is for pull. Triggers are for push.

When a source event fires, NavFlow assembles recent state, joined user, aggregations, and the agent's last memory — then triggers your agent. No fetching loop, no glue code, no per-customer integration.

navflow · dispatch ready
14:07:23 UTC · agent: payment_recovery
source event
stripe.charge.failed · user: 4821 · amount: $142.00 · retry: 3rd
14:07:21 UTC
navflow attaches
recent_state  last 24h of user_4821 · 12 events
joined_user  plan: pro · lifetime: 8mo · ltv $2,140
aggregations  failure_rate_7d: 8.2% · cohort_baseline: 1.4%
agent_memory  last_run: 2d ago · action: email_dunning
prepared 31ms
agent triggered

payment_recovery fires with payload attached.

served via: mcp + webhook · payload: 612 tokens · ready
14:07:23 UTC
the four lanes

Each lane, in plain code. What you'd actually call from your agent.

One MCP endpoint per project. Four ways to read what's in it. And the agent can write its own values back.

  • Real-time

    Stream events arrive normalized to one schema, each carrying the related events from its time window. Your agent receives a clean payload — normalized for readability, kept lossless. Structure without throwing anything away.

    ctx.events
    # → [event, event, event...] last 12h, normalized

  • Historic

    Every event is kept for the project's retention window. Query by time, by key, by filter. Last 7 days, last 4 hours, the last N events for one user — get them back fresh.

    ctx.history(key="user_id", last="7d")
    # → [event, event, event, ...]

  • Aggregations

    Counts, distributions, percentiles, or any derived value you define in the project. NavFlow computes them once when events arrive and caches the result. Your agent reads them as fields, not function calls.

    ctx.last_4h_traffic
    # → 1840

  • Memory

    agent-written

    The agent writes values via navflow.write(). On the next run, read them through MCP like any other source. Useful for last sprint's baseline, prior verdicts, custom flags the agent wants to remember.

    navflow.write(key="checkout_baseline_p95", value=320)
    # next run: ctx.memory.checkout_baseline_p95
who it's for

Built for whoever is shipping the agent. PMs, founders, AI engineers.

If any of these sound like a sprint you've shipped, NavFlow is for you.

PMAI engFounder
  1. PM

    Your agent works in dev, fails in production. Because dev had clean inputs and production is webhooks, file drops, and stale exports.

  2. AI eng

    You've written the same parser three times. OTLP, Vercel webhooks, the customer's bespoke JSON. Your agent gets a different shape from each.

  3. Founder

    You're shipping to multi-tenant customers and every one sends data differently. Half your sprint is product, half is ingestion plumbing.

  4. PM

    The agent fired on the wrong event last sprint. Or fired on the right one, without the prior context that would have made the answer right.

  5. AI eng

    The agent runs in real-time but is blind to history. You've bolted on a vector DB. It's stale by Tuesday.

  6. Founder

    You want one place agents read from, not three. Streams, files, and the agent's own observations, in one project.

what you'd build

From one webhook to a multi-tenant platform. Same project model.

  • 01solo dev · webhook → agent

    Deploys, into Claude. Without writing a parser.

    Vercel deploys and GitHub pushes stream into one NavFlow project. Your Claude agent reads the last hour via MCP before answering questions in team Slack.

    pipeline2 in / 2 out
    ingithub.push
    invercel.deploy
    outclaude (MCP read)
    out→ slack
  • 02team · files + history

    Support tickets, 90 days back. Pulled, not piped.

    Weekly CSV exports drop into S3. NavFlow ingests, indexes, computes the aggregations you defined. Your digest agent queries 90 days of patterns and returns this week's themes.

    pipeline2 in / 2 out
    ins3://exports/*.csv
    inlinear.activity
    outcrewai (MCP read)
    out→ notion
  • 03multi-tenant · pull via MCP

    One project per customer. Many agents per project.

    Stripe events, Postgres CDC, and customer log uploads land in a per-customer project. Multiple agents read the same project over MCP. Zero per-agent ingestion code.

    pipeline3 in / 1 out
    instripe.events
    inpostgres.cdc
    ins3://logs/*
    outN agents (MCP read)
questions

Things people ask before they try.

Don't see your question? Email hello@navflow.ai.

  • How is this different from a webhook router?

    Webhook routers fire and forget — once the request is delivered, the data's gone. NavFlow stores every event losslessly, normalizes it to one schema, indexes it, and serves it over MCP. Your agent reads when it needs to, not only when an event arrives — with queryable history, pre-built aggregations, and its own memory. And unlike memory tools (mem0, Zep), nothing is summarized by an LLM on the way in: your agent reads the real events, not a lossy distillation.

  • Do I have to use MCP, or can my agent use HTTP?

    Both. MCP is the recommended interface and designed for agents. Every project also exposes a normal HTTPS endpoint that returns the same data. Use whichever your stack prefers.

  • What frameworks does NavFlow work with?

    Any agent framework. NavFlow speaks MCP and HTTP. LangChain, CrewAI, AutoGen, Mastra, Inngest, plain Python, plain TypeScript. We don't ship a framework SDK because the protocols already exist.

  • How does the agent's memory work?

    Your agent calls navflow.write(key, value) whenever it wants to remember something. The next run reads it back via MCP, alongside ingested sources. Memory is just one more namespace inside the project, queryable like any other data.

  • What about data residency and compliance?

    Free and Pro run on NavFlow cloud, US-east region. Enterprise tier offers EU, regional, on-prem, or BYOC deployment. SOC 2 in progress; happy to share the current state on request.

  • What if my source isn't supported?

    HTTP and OTLP cover most cases. For anything else, configure a custom HTTP source. It's a single config block, no SDK to install. New first-class connectors ship every release.

  • Can I migrate off NavFlow later?

    Yes. NavFlow stores normalized JSON. Export your project's history and configuration at any time through MCP or the HTTPS API. No proprietary format, no lock-in.

  • Is there a free tier?

    Yes. The Free tier covers 1 project, 100k events / month, and 5 GB stored. Enough for a single agent or hobby project. No credit card required.

Every input, kept whole. Read it over one MCP endpoint.

Create a project. Point sources at it. Read it from your agent over MCP. Free tier, no credit card.

Get started

Already have an account? Log in