In almost every AI project we’ve built, we ended up recreating the same infrastructure.

Pick a topic ->

Scrape sources.
Schedule refreshes.
Deduplicate.
Extract entities.
Embed.
Track changes.
Handle webhooks.
Repeat.

It works.

But it’s surprisingly heavy to maintain.

So we built something simpler: treat a topic like an API endpoint.

The idea

Instead of scraping websites, you subscribe to a topic by -->

POST {the endpoint which varies bw plans}/remem/create
{
  "query": "AI agent frameworks 2026",
  "schedule": "daily"
}

That topic becomes a persistent memory.

It refreshes automatically.
Each refresh creates a version.
You can diff versions.
You can query it anytime.

You’re not querying the web.
You’re querying a continuously maintained topic.

What this replaces

The typical “scraper + RAG” stack looks like:

• Custom scrapers per source
• Cron scheduler
• Storage
• Deduplication logic
• Entity extraction
• Embedding pipeline
• Version tracking
• Change detection
• Alert system
• Webhook retries

That’s 6–10 moving parts.

You can absolutely build it.

We did. Multiple times.

The problem isn’t building it once.
It’s maintaining it across projects.

/Remem collapses that stack into one abstraction:

Why not just use search APIs like Exa or Tavily?

Search APIs are query-time tools.

You ask:

They search the web right now.

That’s useful.

But they don’t:

• Persist results over time
• Maintain version history
• Detect changes between updates
• Track entity-level deltas
• Compute velocity trends
• Send update webhooks
• Build cross-topic semantic memory

Search is stateless.

This is stateful.

Search answers questions.
This maintains evolving context.

Different layer of the stack.

Why not just scrape + RAG?

You can.

But here’s what usually happens:

1. You scrape once.
2. You embed once.
3. Data goes stale.
4. You add refresh logic.
5. Then deduplication issues.
6. Then change detection.
7. Then alerting.
8. Then reliability problems.

Eventually you’ve rebuilt a topic monitoring system.

If you’re building one core product, that might be fine.

If you’re building multiple AI tools,
it becomes repetitive infrastructure.

This abstracts the maintenance layer.

What /remem actually does

When you create a memory:

• First update runs within 1 minute
• Then updates hourly / daily / weekly
• Each update creates a version
• You can diff versions
• You can search across memories
• You can subscribe to webhooks

Under the hood:

• Cross-source aggregation
• Semantic deduplication
• Entity extraction (no generative hallucinations)
• Sentiment + keyword analysis
• 768-d embeddings
• Entity-level change detection
• AI based velocity scoring
• Topic health monitoring

All raw sources are preserved.

No generated summaries are injected into the core data layer.

Example

Tracking:

Without this:

• Scrape GitHub releases
• Scrape blogs
• Scrape funding news
• Scrape Reddit
• Merge
• Deduplicate
• Track deltas

With it:

POST /remem/create
{
  "query": "AI coding assistants",
  "schedule": "daily"
}

Then:

GET /remem/mem_abc123/delta

You get:

• New entities
• Removed entities
• Sentiment shift
• Updated velocity

And optionally:

Webhook sends data if there is a major update

Where this is useful

• Competitor monitoring
• Industry tracking
• VC research
• Keeping RAG contexts fresh
• Monitoring regulatory shifts
• Building market intelligence tools

It’s especially useful when:

• The topic evolves over time
• You care about change detection
• You don’t want to maintain scrapers

It’s not useful for static knowledge.

Tradeoffs

• You’re abstracting away crawling control.
• Version history is currently limited (3 stored per memory).
• If you need deep archival storage, this isn’t that.
• If you need highly custom scraping logic, you’ll still want your own stack.

This is optimized for continuous tracking, not infinite retention.

Pricing

• Create memory: 1 credit
• Each scheduled update: 1 credit
• Reads + analytics: free

Daily tracking ≈ 30 credits/month.

Framing

Web scraping era:

Search API era:

Topic memory era:

If you’re building AI systems that depend on fresh context,
this removes a recurring infrastructure layer.

If you’re building AI systems that depend on fresh context,

this removes a recurring infrastructure layer.

Docs and tool in comments