Here is why:

I love graphs and I use them A LOT!

• for agent memory

• for structuring project context

• for building compounding knowledge bases

Yet old-school graph databases are too heavy for agentic workflows.
They are cloud-first monoliths built for enterprise infrastructure:
Servers, Docker, slow MCPs, and schema maintenance hell.

nanograph started as a question:

What if graphs felt like SQLite/DuckDB - open, query, done - but with types, migrations, and ergonomics built for agents?

Quick to tear down and rebuild, safe enough to trust, and simple enough to keep in the repo.

I could not find a graph database aligned with this vision.
So I built it.

An on-device, embedded, schema-as-code graphDB.

Now let's unpack this:

• Why graph?

• Why on-device?

• Why schema-as-code?

Why graphs?

Graphs help agents reason through data.

Agents are informed walkers.
When an agent investigates an issue, it traverses a context graph.
Graphs give the agent reasoning structures.

Now add decision traces to the equation: the explicit HOWs and WHY - workflows, exceptions, reasoning.

Agent now can:

Solve a problem → walk the graph → write a new trace → graph compounds

New reasoning paths are created - agent becomes even smarter.

BTW the graph doesn't need to be standalone.
It can sit as a semantic layer on top of your data:
SQL/NoSQL or a collection of MD files.

Why on-device?

Coding agents pull us back to fundamentals:
Filesystem, CLIs, Markdown, SQLite/DuckDB.

In PKM, Obsidian is winning, and tools like qmd are getting real traction.

If everything is on-device, everything is simple.
Totally private by architecture, not by policy.
And you can use your own tooling even inside heavily regulated enterprise environments.

Agents want direct, fast, deterministic access to data.
They don't want MCP auth or deal with connection errors.

Why schema-as-code?

Non-enforced schema means garbage accumulation.

Agents are incredibly creative!
Give them a schemaless graph and they will roam free.
They'll invent edges like knows, met, connected_to, spoke_with - all meaning the same thing.
That creates precedent poisoning.
Semantic drift propagates through the reasoning layer.
Your graph becomes noisy, retrieval becomes unreliable.

An established schema prevents it.
And schema-as-code is the best way to enforce it and track changes.

Additional benefit: it captures the evolution of your contract with the agent.
That contract changes as your modeling changes.
Track schema history and the agent can see how your model evolved.
It becomes another super-useful reasoning trail.

So what is nanograph?

nanograph is an on-device graph database packaged as a CLI + a folder.

Engineered around five pillars:

• On-device - the graph is a folder, not a service. No Docker, no cloud, no open ports. Super-fast local queries vs slow cloud roundtrips - compounded across hundreds of agent calls per session.

• Zero setup - nanograph init creates a database from a schema, nanograph load ingests data. Delete the folder and recreate in seconds. No migrations server, no connection strings.

• Schema-as-code - .pg schema files live in your repo, version-controlled right in your repo. Types are enforced at load time and query compile time.

• Time machine - built-in CDC and event sourcing. Every mutation is a ledger entry. Full audit trail without external dependencies.

• Power search - full-text, semantic, fuzzy, BM25, and hybrid search with graph-constrained reranking. Traverse edges to narrow the candidate set, then rank within it. Search inside context, not across the whole database.

A nanograph database is a build artifact, not a running service.
It is a folder: <name>.nano/ that contains all your graph data: copy it, git it, zip it, encrypt it.

Building DB on this paradigm way was quite challenging.

Claude Code and Codex are incredible at writing Rust code.
But when working on specs, architecture and ergonomics - LLMs gravitate towards default thinking and generic components.

Because I wanted to build nanograph as a frontier graphDB,
I dug beneath the surface: researching state-of-the-art open source components.

I was able to figure out a clever interplay between Apache Arrow for memory model and Lance format for storage.
Then I spent a lot of time designing the query language: nanoQL
trying to merge Datalog semantics with GraphQL-shaped syntax.

By this point I had a working prototype, which felt just right!

After having a proof of concept, I dug one layer down and started to work on nuances.
I thought I knew a lot about databases - I've worked with them all my life.
But here I realized that everything is waaay more nuanced and complicated than I imagined it to be.

I went deep into first principles: indexes, compaction, WAL, CDC, caching, ordering, lexical retrieval, hybrid search.

This book was incredibly helpful in figuring out first principles.

After getting the fundamentals right, I started working on specs for each feature super-smart models (GPT-5.2 PRO and Gemini 3 Deep Thinking).

Operating on the edge of my own engineering and math competences,
I was able to optimize all key processes and make nanograph really fast and stable.

nanograph is the most elegant piece of engineering I've ever done.

I really encourage you to try it out!

Quick start

You can just give your agent a link to the repo and it will do the full setup for you:

https://github.com/aaltshuler/nanograph

Or set it up manually:

brew install protobuf
cargo install nanograph-cli

The repo ships two ready-to-run example graphs.

Star Wars graph

A knowledge graph of characters, films, factions, and mentor relationships - 9 node types, 25 edge types, 66 nodes. Great for exploring schema basics, graph traversals, and the full search stack (text, semantic, hybrid).

The schema defines typed nodes with enums and @key identity:

node Character {
    slug: String @key
    name: String
    species: String
    alignment: enum(hero, villain, neutral)
}

edge HasMentor: Character - Character
edge DebutsIn: Character - Film

Init, load, and query:

nanograph init sw.nano --schema examples/starwars/starwars.pg
nanograph load sw.nano --data examples/starwars/starwars.jsonl --mode overwrite

nanograph run --db sw.nano --query examples/starwars/starwars.gq --name jedi
nanograph run --db sw.nano --query examples/starwars/starwars.gq --name students_of --param name="Yoda"

Queries are typechecked against the schema - wrong property names, type mismatches, and invalid traversals are caught before execution.

RevOps context graph

A RevOps context graph:
intelligence capture → enrichment → screening → decision → delivery.

10 node types
21 edge types

This is where nanograph's design really shines: decision traces, policy versioning via Supersedes edges, and multi-hop traversals from signals to outcomes.

nanograph init omni.nano --schema examples/revops/revops.pg
nanograph load omni.nano --data examples/revops/revops.jsonl --mode overwrite

# trace why a decision was made
nanograph run --db omni.nano --query examples/revops/revops.gq \
  --name decision_trace --param opp=opp-stripe-migration

# close the loop: signal → decision → action → outcome
nanograph run --db omni.nano --query examples/revops/revops.gq \
  --name full_trace --param sig=sig-hates-vendor

The decision trace query walks from an opportunity back through who decided and what signal drove it - the kind of "why did this happen?" question that agents need to answer.

What nanograph is best for

• Context graphs (decision traces, causal chains, structured context)

• Agentic memory (typed on-device memory for coding agents)

• Personal knowledge (bookmarks, notes, connections; local-first, schema-enforced, versioned)

• Dependency graphs (services, packages, lineage tracking)

What nanograph is not for

nanograph is intentionally not trying to be everything.

• not a multi-tenant distributed cloud graph

• not an everything-store without schema discipline

• not a transactional system-of-record or ledger

The point is the opposite:
Keep your nanographs compact, isolated, typed, and focused.

Have as many of them as you need.
Init is seconds, delete is seconds.
Spin up per-project, per-agent, per-experiment.

nanograph is open source and free to use.
Your agent will download it and set it up for you,
then help you create your schema and ingest your data.

If you like it - please give it a star on GitHub⭐

In this guide I’ll show you step-by-step how I built MCP Server for Advanced Knowledge Systems.

Using stack:

• ▲ Vercel [ecosystem]

• NEXT.js App Router [backend]

• Vercel MCP‑handler [MCP wiring]

• MongoDB [database + vector index]

• MUX [video storage & transcripts]

• OpenAI embeddings‑3‑small [vector embeddings]

• Claude API [transcript enhancement]

• LangChain text splitters [chunking]

• Clerk [auth]

First let me give you some context.

BACKGROUND

2 years ago I created the course: Advanced Knowledge Systems.

The essence of the course is summarized in the DIKW framework.
I teach people how to build a personal knowledge system that:

• Process DATA

• Organize INFORMATION

• Extract & codify KNOWLEDGE

• Facilitate WISDOM

In just a few days I’ll be running the 14th cohort.
And with each new cohort, this paradigm shift became more and more evident:

FROM: we build the system ourselves
TO: we use agents to build the system for us

This is huge!

It influenced not just how we BUILD but also how I share my know-hows & expertise with cohort participants.

We’re entering a new era of expertise sharing.

It forced me to rethink the ideas of knowledge sharing and expertise from first principles.

Think about it: Until now, knowledge moved primarily from person → person (or person → group).
Now there’s a new stakeholder: AI agent.

Agents like Claude Code, Codex, Cursor, Warp... they changed everything.

I would argue that they are the smartest and most capable tools we ever had
[Like ever… as collective humanity… in any domain]

They are brilliant!

They don’t just write code; they set up environments, manage terminals, connect tools, observe other apps and DO so much more!

This is the crucial part:
For them to be most efficient, they need context: domain-specific knowledge.

And not in the form of static docs & fixed guidelines.
They clutter the context and get outdated very fast.

But knowledge in the form of live, updatable, granular, queryable & searchable knowledge bases with versioning & attribution.

MCPs

This is where MCPs come into play.

What Is an MCP? (Quick Primer)

MCP = Model Context Protocol

Think of it as a smart API for agents:

It’s a standardized server interface that exposes:

Knowledge (facts & frameworks)
Tools (functions & procedures)
Instructions (how to make those useful)

MCP = Toolkit for agents + Guidelines for using it

MCP turns expert methods into interactive toolkit.
Using this toolkit agents can learn, plan, and act through actively engaging with specific know-hows.

Knowledge is a kind of information that’s true and useful
— David Deutsch

MCPs make knowledge operational!

The perfect example here:

Context7

Context7 MCP integrates up-to-date documentation for hundreds of libraries.

Agents can pull fresh knowledge instantly. It’s always up to date and useful.

With Context7 agents don’t rely on stale knowledge from the model weights.
And you do not have to worry that they import outdated libraries or build for non-existent APIs.

Inspired by Context7 [I use it ALL THE TIME] I decided to build my own MCP server following the same paradigm.

An MCP server that acts as a gateway to my methodology, frameworks, and know-hows.

FOR PEOPLE: it provides the way to interact, search, and learn.
FOR AGENTS: it gives the instructions & tools to build working systems.

Now let me show you how I did it.

BREAKDOWN

MVP

Of course I had a grand vision for the project, but I wanted to build the prototype fast.

So now my MCP server exposes 2 core capabilities:

Semantic Search
Fast vector search on course content: lectures, resources, frameworks.

Graph Search
Multi-hop exploration through connected entities: concepts, highlights, resources & tools.

Multi-hop means: when semantic search finds a specific chunk → it can hop to the unit from which this fragment came from [hop 1] → and from the unit to connected resources/highlights/tools [hop 2]

Cohort participants can connect the MCP to any agent and get a companion to the course.

Stack

I started with what I already had:

• Course platform built on NEXT.js

• MongoDB with modules, units, resources, projects

• Clerk auth

For maximum reusability I wanted to build the MCP on top of my existing platform infrastructure: Same backend. Same auth. Same data. Minimal duplication.

Here is the architecture I came up with:

Architecture

AGENT
↓↑
MCP Server
↓↑
NEXT.js (App Router) | ▲ Vercel 
↓↑
Search Libraries [based on Mongo best practices]
↓↑
MongoDB Atlas
  ├─ units/resources/highlights/tools [traditional collections]
  └─ embeddings [collection with vector index]
            ↑
PIPELINE: chunking ← enhancement ← transcripts 
                                      ↑
                                     MUX (video)

Let’s explore all components and logic behind each.

Database

I already use Mongo as the main database for the course platform.
And I wanted to keep all course data in one place:

• One system for units, resources, projects, and embeddings

• Vector index for semantic search

• Native lookups and graph‑style hops

Before this project I knew Mongo’s RAG capabilities were quite good, but I discovered that it can do way more!

In Mongo you can implement:

• Vector search for semantic retrieval

• Graph multi-hop traversal for better reasoning

They enable both traditional RAG and GraphRAG [without federating data across multiple databases].

Storing vector embeddings in Mongo is super easy:
You just need to create a vector index.

Your coding agent can easily do it for you😉

Graph is a bit more complicated: Mongo is not a graph database.
It’s a document database.

That means I had to implement graph traversal on top of this paradigm.

Fortunately, they have this amazing repo for developers with all the examples.

First I copied their Graph RAG approach.
Then I quickly scaffold a simpler dataset for tests & evals → it worked flawlessly!

Now my DB is optimized for both Web App (platform) and RAG:

• Traditional document storage

• Vector storage + vector index

• Schema aligned with multi-hop graph retrieval pattern

Next step: content pipeline to make my course videos accessible for LLMs:
video → transcripts → enhancement → chunking → embeddings → ingestion

Pipeline

I’m using MUX as my video platform. It’s pretty amazing!
Essentially, it’s developer-first video hosting.
It allows you to access all video assets (including transcripts) programmatically.

So I quickly built a content pipeline:

┌─────────────┐
│   MUX Video │
│  (platform) │
└──────┬──────┘
       │
       V
┌─────────────────────┐
│ Fetch Transcript    │
│ (programmatically)  │
└──────┬──────────────┘
       │
       V
┌─────────────────────┐
│ Enhance with LLM    │
│ Claude API          │
│ [clean, denoise,    │
│  normalize]         │
└──────┬──────────────┘
       │
       V
┌─────────────────────┐
│ Chunk Text          │
│ LangChain splitters │
└──────┬──────────────┘
       │
       V
┌─────────────────────┐
│ Generate Embeddings │
│ OpenAI embed-3-small│
└──────┬──────────────┘
       │
       V
┌─────────────────────────────────┐
│ Upsert to MongoDB               │
│  ├─ embeddings collection       │
│  │  [with vector index]         │
│  └─ link with units + metadata  │
└─────────────────────────────────┘

I was able to vectorize and ingest all the course content in just an hour!

Units were already connected to resources, tools, and highlights. So now everything lives in Mongo: clean, queryable, and fast.

With all the data in Mongo, time to move to APIs.

NEXT.js (API for Platform and MCP)

NEXT is not just a React framework [this common misconception still exists]

It’s the backbone of the entire system!

NEXT provides a super neat architecture:
your business logic, API routes, and UI all live in the same codebase.

No need to jump between separate backend and frontend repos.

Since I wanted to have all MCP capabilities on the platform too, I’ve started there:
I integrated the search tools directly into the course platform app (NEXT.js, App Router) so people could use them to navigate the cohort.

Then I extracted the logic into clean libraries and a simple pattern:

• Library + interface + API endpoint

So the course platform and MCP server could share:

• Same DB connections

• Same auth (Clerk)

• Same business logic (search libraries)

• Same API infrastructure (App Router)

This way one backend can power both:

• The web platform (for students)

• The MCP server (for agents)

Both are enabled to:

• Access all course content via semantic search

• Hop across related units/resources/tools

• Pull supporting materials (examples, checklists, frameworks)

• Get structured context in JSON

Reusability is the huge win here! Full-stack TypeScript application using App Router. Auth is also unified: same permissions model everywhere.

So now we have everything ready! It’s time to add the MCP layer.

MCP-handler

Okay, I know I praise Vercel A LOT!

But here’s where Vercel’s ecosystem REALLY shines:
REUSABILITY & INTEGRATION

Vercel provides its own MCP-handler.

So I just wrapped two API endpoints as MCP tools and exposed them via mcp‑handler.

Like this (example from Vercel site):

import { z } from ‘zod’;
import { createMcpHandler } from ‘mcp-handler’;
 
const handler = createMcpHandler(
  (server) => {
    server.tool(
      ‘roll_dice’,
      ‘Rolls an N-sided die’,
      { sides: z.number().int().min(2) },
      async ({ sides }) => {
        const value = 1 + Math.floor(Math.random() * sides);
        return {
          content: [{ type: ‘text’, text: `🎲 You rolled a ${value}!` }],
        };
      },
    );
  },
  {},
  { basePath: ‘/api’ },
);
 
export { handler as GET, handler as POST, handler as DELETE };

That’s it. The mcp-handler handles all the MCP logic and primitives.

Now we have:

• Same backend, same auth, same data [I know, I know, I’ve already said this 100 times😁]

• Now callable from Claude Desktop, ChatGPT, Claude Code, Cursor, Warp…

• [and others] it is compatible with pretty much any MCP client

• Tools return clean, structured outputs for agents to act on

And here we are!

Let me show you it in action:

Warp agent built a framework for selecting optimal Knowledge Hub [fully aligned with with AKS approach]
Of course it will help you to apply this framework next.

IF YOU WANT TO GET ACCESS TO THIS MCP
there is a last chance to jump into AKS Cohort 14 [we have 2 spots left]

What It Enables for Learners & Builders

To summarize:

• Learn‑by‑doing: run the exact procedure an expert would -> install, connect, test, iterate

• Explainability: every step is documented and linked back to sources/graph nodes

• Operationalization: converts inputs → outputs, following know-hows non-linearly

• Acceleration: from idea to system prototype in just hours

VISION

Okay, why this is WAAAY BIGGER than just a course tool.

First I want to emphasize something:

My goal was not just make course content searchable.
But to ENCODE my methodology into something agents could OPERATE WITH.

Every search query returns not just facts & opinions → but context, connections & next steps. Every graph hop surfaces related frameworks & implementation patterns.

This isn’t a documentation.
It’s CALLABLE EXPERTISE.

And IT CHANGES everything:

If I can do this for knowledge management and system design, you can do this for your domain.

The technical pattern here is universal:

• Take domain expertise

• Structure it (relationships, context, provenance)

• Make it queryable & actionable

• Expose it through MCPs

• Let agents apply it at scale

This isn’t about courses.
It’s about how expertise moves in an agent-first world.
Where MCP is becoming No 1 distribution mechanism for know-hows & best practices.

BONUS: FOR EXPERTS

What this revolution means for experts who needs channels to distribute their know-hows and frameworks?

Well, instead of publishing static PDFs or videos, you can now publish executable methods.

Your knowledge is available as a set of callable services:

• Versioned and testable

• Scalable to thousands of users

• Applied systematically by agents

And HERE IS THE THING very few people realized yet: you don’t need to publish CODE.

You publish:

• Approaches

• Guidelines

• Frameworks

• Decision heuristics

The agent will handle the implementation! following user context and relevant aspects of your method! [for now not flawlessly, but think 6 months from now, when new generation of models is here]

And this goes waaaaay beyond tech-heavy domains.

For example:

For Nutrition Experts

Your method can be embedded into personalized nutrition assistant

Agent accesses [PRIVATELY]:

• Client’s health data from wearables (metrics, activity, sleep)

• Food intake patterns and logs

• Parsed and mapped food photos

• IoT kitchen devices & meal prep

And with your expertise MCP, it can:

• Build personalized plans grounded in YOUR methodology

• Deliver timely interventions based on YOUR protocols

• Flag nutrient gaps and suggest substitutions from YOUR system

• Adapt recommendations as data evolves

For Coaches

Your framework can become a scalable coaching companion

Agent accesses data [PRIVATELY]:

• Client’s session transcripts & recordings

• Journals & reflections

• Progress logs & goal tracking

• Assessment results (Clifton, BIG-5, ..)

And with your expert MCP, it can:

• Apply YOUR coaching model to each client’s situation

• Ask probing questions from YOUR methodology

• Surface relevant frameworks and tools from YOUR playbook

• Track growth patterns using YOUR checklists

• Suggest next steps aligned with YOUR approach

For Analysts & Strategists

Your analytical frameworks become decision-support systems.

Agent accesses data [PRIVATELY]:

• Client’s business metrics & KPIs

• Market research & competitive intel

• Strategic documents & planning artifacts

• Historical decisions & outcomes

And with your expert MCP, it can:

• Apply YOUR UNIQUE analytical lens to each situation

• Generate scenarios using YOUR strategic frameworks

• Validate reasoning against YOUR specific set of criteria

• Run analyses using methods curated by YOU.

• Produce reports in YOUR specific format and style

NOT generic advice.
Your specific methodology.
Applied to Client’s context.
At scale.

The pattern is the same:
MCPs turn expertise into callable procedures.
Agents apply procedures to specific context and turn them into outcomes.

We’re entering a new era of expertise sharing.
The next decade’s leverage comes from agents equipped with expert know-hows.

If you want your ideas used: DON’T WRITE A BOOK → expose them through MCP!

Okay, now it’s time to ship something🚀

If you want me to help you build the MCP system:
DM me here or enroll to Accelerated/Discovery track of AKS

After 16 months of building AI agents I finally have a production stack where everything just works together.

Here's what I'm using:

• NEXT.js (runtime)

• Vercel AI SDK (LLM core logic)

• Mastra (agentic framework)

• AI Elements (UI components)

• Mem0 (memory layer)

• OpenTelemetry & SigNoz (traces)

• Vercel (deploy)

It's perfect!

No duct tape. No clunky integrations. Deploys in seconds.
Full-stack TypeScript. One deployment.

Let’s unpack it and I show you why it's so good.

But first, some background…

Python vs TypeScript

When you're entering the AI agent dev space, your first big decision is Python vs TypeScript/JavaScript.

Historically Python dominated AI/ML. Most early agent frameworks (LangChain, CrewAI, AutoGen) built on Python.

Today there are quite a few amazing agentic frameworks in Python ecosystem.
My favorites: Google ADK, Agno. You can build powerful agents with those.

Yet Python has a problem: UI.

When you need a modern React-based web UI you're going to need to integrate two stacks: Python for the AI core + JavaScript for the frontend.

Two languages, two ecosystems, two deployments. Workable, not ideal.

But here's the good news: the TypeScript AI ecosystem really caught up!

And with incredible ▲ Vercel leadership it's starting to dominate in builders community.

You can think of it this way:

Python → best for delivering models: data, training, inference, ML ops
Typescript → ideal to ship products: UI/UX, business logic, orchestration, scaling

My entire stack runs on TypeScript and relies heavily on Vercel Ecosystem.

Let me walk you through every component of it.

The Breakdown

NEXT.js: Runtime

NEXT is not just a React framework [this common misconception still exists]

It's the backbone of the entire app!

It handles:

• Agent runtime

• API routes (backend <> frontend)

• Frontend logic & rendering

• UI/UX

NEXT.js provides a super neat architecture:
your AI logic, API routes, and UI all live in the same codebase.

No need to jump between separate backend and frontend repos.

Vercel AI SDK: LLM Scaffolding

A TypeScript SDK for LLM interaction & logic.

It’s a layer of abstraction that provides: streaming, tool calls, structured outputs, UI hooks.

Key benefits:

• Vercel native [yet works with other framework too]

• Type safety: 100% TypeScript support

• LLM agnostic: You can use OpenAI, Anthropic, Google, Groq and more

• Great developer experience: Super clean API + amazing documentation

AI SDK is the foundation agentic frameworks build on.

BTW AI SDK is evolving to include more agentic features itself.

Mastra: Orchestration

While AI SDK handles LLM logic beautifully, agents need orchestration.

Here's where Mastra comes in!

Mastra is an open-source agentic TypeScript framework built on top of AI SDK.

Think of it this way:

AI SDK = scaffolding for LLMs
Mastra = scaffolding for Agents

Mastra provides the core AGENT abstraction:

export const simpleAgent = new Agent({
  name: “Simple Agent”,
  instructions: “You are a helpful assistant. You can use the simpleTool to do X ...”,
  model: openai(”gpt-5-nano”),
  memory: new Memory(),
  tools: {
    simpleTool,
  },
});

As you can see It handles:

• System prompt

• Model selection

• Tool calling

• Memory

Using these, you can create really complex agentic behavior.

And this is what many people are missing:
building agents is 50% tech and 50% behavior engineering.

Mastra gives you an amazing PRO toolkit to handle both.

It includes:

• Memory curation

• Runtime control

• Multi-agent wiring

Using these, you can orchestrate multiple agents into a very sophisticated AI system.

And this system needs a UI, right?

AI Elements: UI

AI Elements gives you production-ready UI components out of the box.

Built with shadcn, Radix and Tailwind:

• Chat flow

• Output renderer

• Loaders / controls / selectors

• Error handling

You can build a ChatGPT-like interface in no time:

All fully customizable: you can skip frontend wiring & UI nuances, and focus on your agent logic & UX.

Mem0: Long-Term Memory

One more quick background snapshot:

The biggest shift happening in AI right now: STATELESS → STATEFUL

We're used to stateless AI that:

• Forgets previous interactions

• Starts from scratch every time

• Feels inconsistent and robotic

Sure, we've had RAG for a while, but retrieval ≠ memory.

RAG-enabled agents still suffer from amnesia.

True memory changes everything:

• Quick recall from multiple interactions

• Better reasoning through context awareness

• Self-improvement over time

• Personalization and trust

And yes, Mastra already handles a lot of memory features (working memory, conversation memory, semantic recall).

But I like my agents to be truly personal and sharp!

I need them to be peaky: to remember specific facts across threads.
To hold all important user preferences and decisions.

This is where Mem0 comes in: it gives agents a persistent, searchable & manageable memory layer.

And it gives you another orchestration and behavior engineering tool.

Mem0 works well with Mastra and can be integrated with just a few lines of code.

But of course with each additional library your agent is becoming more complex and error-prone…

OpenTelemetry + SigNoz: Traces

Complexity is inevitable in real-life agentic systems.

When your agent performs a sophisticated non-linear task, it might involve dozens of LLM calls and tool executions.

You need to see what's happening there:
track errors and find non-optimal flows.

OpenTelemetry enables your agent to produce traces.
In SigNoz you can query them and visualize.

You can trace:

• Tool calls

• Latency & token usage

• Bottlenecks & failures

Mastra already has OpenTelemetry integrated! You just need to set up SigNoz routing.

This is mandatory for production:
when your agent goes off the rails at 3 AM, you need those traces.

Vercel: Deployment

NEXT.js → Vercel deployment is brilliant!

The entire app deploys with one command.
No separate Docker configs. No complex DevOps pipelines.

Just

git push

That's it!

Vercel handles:

• Minimal-config serverless deploy

• Continuous integration

• Automatic scaling

And so much more!

Why This Stack Works

So after trying dozens of combinations, this stack is a clear winner for me.

Everything is TypeScript. Every component understands the others.

Mastra is built on AI SDK, has integrated OpenTelemetry and native support for Mem0.
NEXT.js, AI SDK, AI Elements are all parts of Vercel ecosystem.
They all click together like LEGO blocks.

No glue code. Great developer experience. Minimalistic API.
Full observability. One command deploy.

16 months of experiments, failed integrations & all-night debugging sessions, but I finally found it: my perfect agent stack!

In this guide I'll show you how to build an agentic business assistant that works for you 24/7, syncs your entire business context, and gets smarter over time.

Stack

• Claude Desktop

• Claude 4 [Opus/Sonnet]

• MongoDB + MCP

• Filesystem MCP

• GCal & Gmail integrations

• Obsidian / Zed [to view briefings]

• Wispr Flow / superwhisper [voice input]

• v0 + Vercel [dashboard → optional]

Why I Built This Assistant

It’s time to admit it: traditional productivity software is broken.

It forces you to:

• Copy-paste things between different apps

• Work as a data entry clerk

• Constantly keep in mind dependencies

It’s just exhausting!

Automations and AI workflows helped a bit.
But the main problem remains: they hold only limited context.
[not seeing the full picture of your business].

They can sync data, but they don't know WHAT matters & WHY.

So I built an agent that holds the FULL CONTEXT of my business:

• My goals and priorities

• Tasks, projects, clients

• Structure and dependencies

• Current state of affairs

Now I can simply dictate:

“Meeting with Sam done - he approved the project, wants to start in July. Update proposal status. BTW add 2 new subscriptions to tracker, and prepare full briefing on tomorrow's priorities”

Assistant breaks it down, syncs everything, and gives me an updated briefing.

I use it to:

• Stay on top of tasks & projects

• Track my CRM & opportunities

• Better manage my schedule

• Automate my finances

Extensive knowledge helps it to be very smart, contextual and precise.

The agent-first productivity is here!

If you're still alt-tabbing between 5 apps & wasting time on data entry ... ngmi

But no worries you are not late to the party.
All this became a reality just a few months ago:
with new generation of models [o3, Gemini 2.5 PRO, Claude 4] & updated MCP.

So let me show you how to build the assistant like that.
I broke the whole process into 7 steps.

STEPS

1️⃣ Set up MongoDB free instance [10 minutes]
2️⃣ Connect MCP servers to Claude Desktop [10 minutes]
3️⃣ Create your data schema [20 minutes]
4️⃣ Set up Claude project [30 minutes]
5️⃣ Set up other integrations (GCal, Gmail) [5 minutes]
6️⃣ Create daily briefings / dashboard [20 minutes]
7️⃣ Give it a spin!

Let's go step by step. I'll provide you with detailed guidelines, prompts, templates, and configs.

1️⃣ Set up MongoDB free instance

I use MongoDB as a memory for the agent and single source of truth for everything that is happening in my business.

Why MongoDB?

Mongo is super flexible. Way more flexible than traditional SQL databases.
SQL forces everything into rigid tables with predefined columns. MongoDB stores "documents" → flexible containers that hold whatever information you need.

Need to add a new field? Just add it. No restructuring required.

This flexibility is perfect for AI assistants.

Let’s set it up!

STEPS

[1] Create Your Account

• Go to mongodb.com/atlas

• Sign up with Google or email

[2] Create your free cluster

• After signing in, click Create cluster

• Choose the FREE tier

• Pick your cloud provider [AWS is fine]

• Choose the region closest to you

• Name your cluster something simple like "business-assistant"

• Click Create Deployment

[3] Get your connection string

After your cluster deploys (takes 1-3 minutes), MongoDB will provide a connection string. It’s gonna look something like this:

mongodb+srv://claude-assistant:<password>@cluster0.xxxxx.mongodb.net/?retryWrites=true

This is the only thing you need to connect MongoDB to Claude via MCP.
Save it → we'll use it on the next step.

2️⃣ Connect MCP servers to Claude Desktop

What is MCP?

Model Context Protocol (MCP) is an open protocol that standardizes how LLMs/Agents interact with apps / tools / data sources.

It's essentially a smart API that:

• Provides the connection protocol

• Contains instructions for the agent on how to use this protocol

With MCP Claude can skilfully use many tools.
To set up MCPs you need to install Claude Desktop.
And you need to have Pro or Max subscription.

STEPS

[0] Set up your first MCP server

If you've never used MCP → start with the Filesystem MCP [we'll need it later anyway]. This MCP allows Claude to read/write files on your local computer in specific folders.

Here is the official guide on how to set it up.

When you are done → test it with a prompt:

Create a text file with “Hello world” inside

Check if the file was successfully created.

Perfect ☑️

[1] Set up MongoDB MCP

Now let's connect MongoDB MCP.

Add this part to your Claude Desktop config:

{
  "mcpServers": {
    "MongoDB": {
      "command": "npx",
      "args": [
        "-y",
        "mongodb-mcp-server",
        "--connectionString",
        "mongodb://localhost:27017/myDatabase"
      ]
    }
  }
}

Change connection string to the one we got on the first step.
Your config will look like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/username/Desktop",
        "/Users/username/Downloads"
      ]
    },
    "MongoDB": {
      "command": "npx",
      "args": [
        "-y",
        "mongodb-mcp-server",
        "--connectionString",
        "mongodb+srv://claude-assistant:<password>@cluster0.xxxxx.mongodb.net/"
      ]
    }
  }
}

[2] DOUBLECHECK👀

It should have:

• Real username for filesystem

• Your connection string for MongoDB

• Config file formatted correctly (ask Claude or other LLM to verify it if you are not sure)

Now your Claude is connected to MongoDB MCP and ready to access your database ☑️

Time to put some stuff in there!

3️⃣ Create your data schema

In MongoDB data is stored in JSON-like format.

Claude will help you to create a collection for each data type. Most basic ones:

• tasks

• projects

• people

• opportunities

• expenses

Think of a collection as a table in traditional database.

STEPS

[1] Define the basic data structure for each collection

This is where MongoDB's power shines: you don't have to make it rigid and follow it for every item.
New entries can miss fields or introduce new fields.

Example: projects collection

[
  {
    "_id": "wonka_consumer_research_2025",
    "name": "Wonka Consumer Research Project",
    "description": "Research for Wonka Industries new product line",
    "status": "active",
    "client": "Wonka Industries",
    "budget": 25000,
    "currency": "USD"
  },
  {
    "_id": "finance",
    "name": "Finance & Administration",
    "description": "Expense reporting & budget tracking",
    "status": "ongoing"
  }
]

Notice how these two entries share some fields but not others.
But all of them have unique IDs (slugs). We will use them to make connections.
BTW you do not have to input them yourself → Claude will do it for you.

[2] Connect collections

Now here's how you connect tasks with projects using ID (slug):

[
  {
    "_id": "reply_client_email_sarah_timeline",
    "title": "Reply to Sarah's email about project timeline",
    "projectId": "wonka_consumer_research_2025",
    "priority": "MEDIUM",
    "deadline": "2025-06-28",
    "status": "todo"
  },
  {
    "_id": "submit_expense_report_may_2025",
    "title": "Submit May expense report",
    "projectId": "finance",
    "priority": "HIGH",
    "deadline": "2025-06-30",
    "notes": "Include receipts from client lunch and conference travel",
    "status": "done"
  }
]

In tasks collection you need to have projectId field.

[3] Customize structures

Add relevant fields. Think about what fields might be unique to your business / your personal style.

For example:

invoiceTerms, dependencies, stakeholders, recurrence

Ask Claude to help you to design your schema.
When satisfied → move to the next step.

[4] Customize structures

Make sure you have MongoDB MCP connected:

Ask Claude to create the collections with your real data.

Use these prompts:

Create MongoDB collection 'projects' and add data: 
<paste your projects in structured format>

Create collection 'tasks', connect to relevant projects via projectId. data:
<paste your tasks in structured format>

Once you have real data in MongoDB, it's time to set up the agent.
We will use Claude Project for that.

4️⃣ Set up your Claude Project

Claude is not just a chatbot. It has agentic abilities:
it can make decisions, use tools and take actions.

You can think of Claude Project as agent template. It allows you to define a consistent identity & instructions with a system prompt. Plus add specific knowledge to your agent.

Steps

[1] Create your project

• Give it a name and description

• Project becomes your dedicated workspace

[2] Add your system prompt

The system prompt defines your agent's identity and how it should use tools.

Balance is key here:

• If prompt is too strict → it will limit autonomous thinking

• If prompt is too vague → agent’s behaviour will be inconsistent and misaligned

Here's a template you can start with:

<!-- Template Usage: Replace {{placeholder}} with your specific information. Comments provide examples and guidance. -->
ROLE: Business and work management assistant

## Coordinate Work  
Manage my workflow utilizing these native entities:  
**tasks** [work tasks] the atomic, actionable step  
**projects** – projects, products, or ongoing responsibilities
**{{YOUR_OTHER_ENTITIES}}**
<!-- Examples: goals, habits, expenses, etc. -->

IMPORTANT: Resources are stored in MongoDB in {{DATABASE_NAME}} database in collections:
<!-- Replace DATABASE_NAME with your actual one, for example: business-assistant -->
tasks, contacts, projects, {{YOUR_OTHER_COLLECTIONS}}

Day-to-day briefings stored in local files in this format:
work-briefing-<DATE>.md
Briefings act as daily todo lists.
The updated form should be reflected in MongoDB

MongoDB - single source of truth
Local briefing files - fleeting todos
use reference.md as an inspiration structure for daily briefings

## Calendar
You have access to my Google Calendar
Consider it when relevant

## Relationship Management  
Track contacts, opportunities, and relationships for:  
**Professional Network**  
**Client Relations**
**Personal Connections**
**{{YOUR_RELATIONSHIP_CATEGORIES}}**
<!-- Examples: Industry contacts, mentors, collaborators, vendors, etc. -->

## Content & Communication  
Plan, schedule, and repurpose material across:  
**X/Twitter**
**Newsletter**
**{{YOUR_CONTENT_PLATFORMS}}**

## {{YOUR_OTHER_AREAS_AND_TOOLS}}
<!-- Example areas: personal growth, finance, etc. -->
<!-- Example tools: email, GoogleDrive, Notion, etc. -->

---
# HOW

# How to Assist
**Ingest & Organize** – Extract items and translate them into the correct entities (Task, Project, Contact and so on).  
**Surface What Matters** – Proactively highlight high-impact Projects, important contacts, and upcoming deadlines.  
**Suggest Next Actions** –Try to recommend concrete, appropriately sized Tasks.  
**Keep Everything Linked** – Ensure each contact, project, task and other items have references / are referenced (where relevant).  
**Maintain Momentum** – Offer clear priorities, checklists, and lightweight dashboards while respecting the preferred structure above.

## Communication Style
Be concise but actionable.  
Use plain language; avoid jargon unless it's already in use.  
Ask clarifying questions only when information is missing or ambiguous.

## VALUE
Remember: Your value lies in turning scattered items, notes, ideas, and opportunities into an integrated engine that advances the business, delights clients, and ships content consistently.

Adjust it to match your business needs & structure.

[3] Add business knowledge

Don't try to put everything into the system prompt.
Instead, add specific knowledge to the project context → Claude uses RAG (Retrieval Augmented Generation) to access it efficiently.

Examples of what to add:

• Service offerings

• Client and partnership information

• Operating procedures

• Pricing structures

• Team roles and responsibilities

• Hiring practices

Boom! Now your agent is operational ☑️

5️⃣ Set up additional Integrations/tools

Let’s integrate some useful tools.

STEPS

[1] Integrate calendar & email

Connect Claude to your Gmail & Google Calendar natively using integrations available in Claude Desktop: simply click Connect and authenticate Claude using your Google account.

To connect Claude to different providers like Outlook or Microsoft 365 → use MCP.

[2] Add voice input

At the moment, Claude Desktop doesn't have native voice input.
So you need a tool for that.

I use Wispr Flow [Mac]. It's the fastest and most accurate Speech → Text translator I know.

superwhisper would be another good option.

Now Claude has access to more contexts and you can talk to it ☑️

6️⃣ Create daily briefings / dashboards

Your assistant is fully operational and you can interact with it via chat interface.

But it’s not always optimal.

Sometimes you still want to have GUI (Graphical User Interface) to interact:
dashboard, to-do list, kanban. Something familiar for contextual input / adjustments.

Here is how you can do it:

Option 1: Markdown daily briefings [EASY]

The simplest approach is to use markdown:
Fleeting documents that provide a snapshot of your business on a given day.

Here's an example (in Obsidian):

It’s well structured and you can use mermaid diagrams.

To set this up:

[1] Add formatting rules to your system prompt

## USE these work-briefing formatting rules

Optimization
- **NO** backticks for emphasis
- **NO** HTML tags
- **USE** bold text for important items
- **USE** Mermaid diagrams: `pie`, `timeline`, `quadrantChart`

Callout Strategy
- **Only 4-5 callouts** per document
- **Position:** Next to headers, NOT containing content
- **Purpose:** Navigation and context only

```markdown
> [!danger] Impact Alert
> Context about risks, not the tasks themselves
```

Key Principles
1. **Tables:** Use markdown tables for structured data
2. **Checkboxes:** `- [ ]` for all actionable items
3. **Emphasis:** Bold text, not backticks
4. **Visual bars:** Use █ and ░ for progress
5. **Sections:** Clear with `---` dividers

Remember
- Callouts = Context providers, not containers
- Mermaid = Visual intelligence
- Tables = Structured data
- Bold = Important text
- Emojis = Quick scanning

use briefing template: briefing_template.md

[2] Upload briefing template to Claude Project

[3] Use the Filesystem MCP to write daily briefings directly to your system.

Prompt:

Create a full daily briefing for me <current date>

[4] Use Obsidian / Zed / Cursor or any other MD editor to view briefings and make changes.

Important: When you manually edit a briefing, tell Claude explicitly:

I've updated the briefing, please sync these changes to MongoDB

Option 2: MongoDB Compass [MEDIUM]

MongoDB has a visual client: Compass.

You can view / query / filter / edit your data using a relatively simple UI.

Option 3: Web-app dashboard [ADVANCED]

The more advanced approach:
building a proper dashboard on top of MongoDB.

It can be fully customized to show your tasks, projects and other items in a structured, familiar interface.

I use v0 + Vercel + MongoDB for this.

v0 can easily generate dashboard prototype for you. Yet syncing it with MongoDB requires some coding/deployment skills.

And there you have it! We’re all set ☑️

7️⃣ Give it a spin!

Your system is fully operational. Time to test it!

Try these prompts:

Give me today's briefing

What are my most important opportunities?

Show me all upcoming deadlines

Which clients haven't I contacted in 30+ days? 
Create a contact strategy to reach them

Create an action plan for next week's priorities

Add task X and make it priority for today

Watch as Claude:

• breaks down requests into granular items

• connects the dots between scattered emails, meetings & tasks

• analyzes your business situation 360°

• creates contextual artefacts & strategies

• evaluates opportunities and risks

This is your new business powerhouse ☑️

Wrapping Up

For me this build was life-changing!

Instead of being a data clerk for clunky productivity tools, I now just talk to Claude.
It handles the tedious stuff while surfacing patterns & opportunities I was too busy to see.

With memory features coming soon, it'll get even smarter: remembering our interactions and considering them every time we speak [additional layer of memory to MongoDB]

Not everything will be smooth of course.
Expect some rough edges:

• Your first version won't be perfect

• MCPs occasionally glitch

• Claude might confuse tools (for example: create files when you want chat responses → just say "return in chat, don't create a file"

• You still need to do some manual input and clean-up

  [for example: deleting out-of-date briefings to avoid context poisoning]

You'll hit some paper cuts & bugs for sure.

But it should not stop you! Spend time with your agent. Tweak the system prompt. Update the knowledge base. Give it feedback.

Within a month of daily use, it'll be aligned with you almost perfectly.
And with new models & MCP updates, your assistant will keep getting better.

You're not just building a tool.
You're building a partner that evolves with you, making you more productive and less overwhelmed every single day.

In just a few years, the whole thing exploded from simple chatbots into a maze-like ecosystems of tools, platforms, and frameworks.

It is defined by:

COMPLEXITY

Agents integrate dozens of moving parts → LLMs, vector stores, orchestration layers, guardrails, feedback loops… The overall system quickly becomes too tangled to understand.

WARP SPEED EVOLUTION

Yesterday's best practice is today's legacy. Everything feels like it's changing constantly.

As someone who is pretty good at keeping up with AI, I can barely keep up with it all. That leads me to believe that very few other people are keeping up, either

—Ethan Mollick

SCATTERED KNOWLEDGE

Insights hide in industry newsletters, GitHub docs, conference videos, and Slack communities.

All this creates CONFUSION.
Multiplied by social media where buzzwords spread faster than careful explanations.

The Agentic Periodic Table is my attempt to break these vicious loops.

• Untangle the complexity

• Provide scaffolding for agent builders

• Give teams a shared vocabulary

• Establish a tracking system for industry updates

• Give newcomers a clear map to the landscape

Let’s dive into it!

FRAMEWORK

In a nutshell it goes like this:

AI agents → autonomous systems powered by LLMs.
They possess distinct Characteristics & Attributes
Agents can perform a number of Activities
They are constructed from key Building Blocks
Agents interact following certain Patterns.
You can employ ready-to-use agents.
Or build your own using different approaches.
Custom agents need continuous Ops to remain robust.

Now let’s explore each category.

ATTRIBUTES

An agent begins with a clear Goal and a stable Identity.
Goal → the specific outcome the agent is built to deliver.
Identity → a fixed persona and purpose that shape responses and actions.

To achieve its goals, an agent relies on Working Memory to hold active context and Long-term Memory to retain knowledge across sessions.

Identity & goals are stored in long term memory.

The agent can take Actions using a curated set of Tools (browser, web-search, code execution and so on).

Actions influence the Environment → the digital or physical space the agent operates.

Internal State → a live snapshot of what the agent is currently doing:
“I’m planning, writing code, accessing an API right now”

Control Flow → logic that picks the next step (change Internal State).
Agents often use Loops in the control flow to iterate and improve outcomes.

Throughout operation, Guardrails (safety constraints) ensure safety boundaries.

Most common Guardrails: Human-in-the-Loop checkpoints → where people review or override decisions.

Efficiency of the agent can be measured by Latency & Cost.
Latency → time the agent takes to respond or finish a task.
Cost → resources spent to operate, from tokens to API fees.

BUILDING BLOCKS

LLM serves as the agent's "brain," enabling it to → reason, plan & understand instructions.

Instructions explicitly steer the agent's behavior.
They include: directives, guidelines, rules, and constraints

Frameworks provide the structural scaffolding for agents,
integrating models, tools & memory.
Frameworks encapsulate a lot of low-abstraction processes (chat logging, tool choice logic and so on).

Vector DB + RAG give the agent an on-demand knowledge base & act like long-term memory. Vector Databases store data as embeddings (meaning converted to numbers).
Using RAG, the agent pulls the closest matches into its context when needed.

MCP acts as a "smart API" that comes with built-in instructions for agents on how to use tools.

Tools give the agent hands-on abilities to interact with Environment:

• Computer use → manage files, run terminal commands, interact with a virtual OS

• Code sandbox → safely write and execute code snippets in isolation

• Browser use → open pages, click links, fill forms, scrape content

• Web search → query engines for real-time data & up-to-date knowledge

ACTIVITIES

Reasoning → evaluating information to build logical chains that inform action.

Planning → breaking complex tasks into manageable steps and sequence them.

Decision-making → autonomously selecting the next action based on goals & context.

Executing → performing the chosen action within the environment using the toolkit.

Error handling → detecting failures & trying to solve them

Self-improvement → learning from outcomes and updating strategies (updating memory)

CHARACTERISTICS

Modularity → built from interchangeable modules connected by clear I/O interfaces.

Reliability & safety → performs correctly and avoids harmful outcomes.

Alignment → keeps goals and actions consistent with human intent and values.

Reactivity → senses changes and responds in real time.

Social ability → communicates and coordinates with other agents to achieve tasks.

Autonomy → decides and acts without constant human oversight.

OPS

Once an agentic system is live → continuous Ops keep it reliable, efficient & up-to-date.

Orchestration → coordinating multiple agents, tools, and pipelines into one coherent workflow.

Deployment → packaging your agent and making it easily accessible [just for you, your team, or a larger audience]

Scaling → Expanding agent’s capabilities & performance, taking it from quick no-code prototype into high-performance products.

Cost Opt → watches spend and routes work through the most economical path.

The way you choose to implement agents also falls under the Ops umbrella:

• Ready-to-Use → drop-in agents that work out of the box.

• No-Code → build and adjust agents entirely through visual interfaces.

• Low-Code → mix drag-and-drop blocks with light scripting for extra control.

• Pro-Code → full programmatic access & deep customization.

Wrapping up

So now you have it → a map. Keep it on the dashboard. Save it, bookmark it, print it, whatever works.

Use it as a checklist, study guide, or team dictionary.
And if it clicks—drop me a line!

I'm genuinely curious to hear your story

I’m launching AgentsWorkshop⚒️

Your go to place to learn how to design & build useful AI agents + curate your personal AI toolkit.

INSIDE

• Practical, step-by-step guides

• Detailed case studies

• Ready-to-use templates & patterns

• Interactive demos and teardown sessions

• AI industry updates (clear signals, no noise)

OUR FOCUS

Building AI agents & LLM-powered workflows for:

• Personal productivity

• Project management

• Knowledge & information management

• Everyday Ops (CRM, Sales, Analytics, …)

• Learning & accelerated expertise

TOOLKIT

Ready‑to‑Use Agents & AI-tools

Manus, DeepResearch, Notebook LM, Cursor Agent, v0

No‑Code & Low‑Code Builders

Lindy, Tana, LangFlow, Flowise, LangChain OAP

Frameworks & SDKs

Google ADK, OpenAI Agents SDK, LangGraph

FIRST PRINCIPLES

We rely extensively on:

• Domain-Driven Design

• System Architecture

• Experience Design

Learn how to BUILD AI solutions with clarity & confidence + USE tools like a PRO🧰