DEV Community: Nguyen Thien

We built Nebula: GraphRAG that runs in your browser tab, not someone else's cloud

Nguyen Thien — Tue, 30 Jun 2026 13:19:40 +0000

Most AI note apps ship your notes to a cloud vector database and a hosted model, then ask you to trust the privacy policy. For the work we do (regulated industries, sensitive data) that is a non-starter. So we built the opposite and open-sourced it: Nebula, a private, local-first AI knowledge base that runs entirely inside a browser tab. No backend, no account, no server. Its tagline says it plainly: notes that think, nothing leaves your device.

Repo: https://github.com/beevr-labs/Nebula (Apache-2.0). Live demo, no signup: https://beevr-labs.github.io/Nebula/. Here is why we went fully on-device, and what it cost.

Privacy by architecture, not by promise

The usual privacy pitch is a policy: "we won't look at your data." Nebula's is structural: there is nowhere for your data to go. Everything runs in the browser. Notes, embeddings, and the search index live in local browser storage. There is no sync service, no account system, and therefore no server to breach or to put under a data-processing agreement. For sensitive notes (client records, health information, anything you would not paste into a cloud chatbot) that is the whole point.

What runs where

It is a SvelteKit single-page app that does real ML in the browser:

On-device chat via WebLLM, GPU-accelerated with WebGPU. You pick the model, from tiny-and-fast to large-and-accurate, and Nebula shows the download size before you commit. Qwen and Llama models are supported.
Semantic search powered by bge-m3 (Apache-2.0), about 570 MB on first use, then cached and fully offline. It is multilingual, including Vietnamese, so it works across mixed-language notes.
WebAssembly handles the compute-heavy parts.
After the first model download, the whole thing works offline.

Why a graph, not just vectors

Flat vector search finds notes that are similar. It does not understand that "the client from the Tuesday call" and "Acme Corp" are the same entity across ten different notes. Nebula builds an entity knowledge graph automatically (people, projects, clients) and uses GraphRAG to answer questions by walking those relationships, then links every answer back to the source notes. You ask in plain language and get an answer you can trace, instead of a keyword hunt across disconnected files.

It is also just a good notes app

The AI is useless if the notes app underneath is not real, so it is: Markdown, wikilinks and backlinks, tabs, a quick switcher, daily notes, templates, tags, and folders. You can bring your own files (PDF, CSV, text) and export the whole vault as plain .md files whenever you want. No lock-in: your notes go in and out as portable Markdown. The codebase ships with 430+ automated tests, because local-first does not mean fragile.

The hard parts (what we learned)

On-device models are smaller, so structure has to carry more weight. The knowledge graph recovers context that a small local model alone would miss, which is a big part of why we went graph-first instead of leaning on raw model size.
Explainable retrieval matters as much as accuracy. Showing the path through the graph back to source notes is what makes the answer trustworthy, and for regulated buyers that traceability is not a nice-to-have.
The browser is a surprisingly capable runtime in 2026. WebGPU plus WebAssembly means "install nothing, runs offline, GPU-accelerated" is actually achievable, not a science project.

Why open source

The same reason we open-source the rest of our hardest work: in AI, "verifiable" beats "trust me." A buyer evaluating us for sensitive data can read exactly how retrieval works, and confirm for themselves that nothing leaves the device, instead of taking our word for it.

Nebula is Apache-2.0 at https://github.com/beevr-labs/Nebula, with a live demo at https://beevr-labs.github.io/Nebula/. If you need AI built on sensitive or regulated data, on-device or otherwise, made to survive an audit rather than just a demo, here is how we work.

Anyone else running RAG fully in the browser? What model and hardware combo is actually working for you?

Originally published on beevr.ai.

We open-sourced Kite, our agent framework. Here is what building production agents taught us.

Nguyen Thien — Tue, 30 Jun 2026 13:17:37 +0000

Everyone has an agent demo in 2026. Far fewer have agents they would put in front of a paying customer, an auditor, or a patient. The gap between "it worked in the notebook" and "it works every time, safely, and we can explain what it did" is where most agent projects quietly die, and it is the gap we built Kite to close.

We just open-sourced it: https://github.com/beevr-labs/Kite. It is Python, MIT licensed, and pip install kite-agent away. This is the honest writeup of why it exists and what we learned.

The problem Kite solves

We build production software for regulated industries, so we kept hitting the same wall: the popular agent frameworks are great for a prototype and painful for production. Getting to a first working agent in LangChain or AutoGen is a configuration project, and once you are there you still have to bolt on the parts that actually matter in production: guardrails, retries, idempotency, observability, evaluation. We were rebuilding that same scaffolding for every client. Kite is the framework we wish we had started with: opinionated about safety, fast to a running agent, and small enough to read.

The one design decision everything hangs on: treat the LLM as untrusted

This is the core idea. In Kite, the model proposes actions, it does not execute them. A controlled kernel sits between the agent and the real world and validates every proposed action against policy before anything runs. So when an agent decides to call agent.run("rm -rf /"), the kernel refuses it instead of your filesystem finding out the hard way.

It sounds simple. It changes everything about how comfortable you are giving an agent real tools. The model becomes a planner you can sandbox, not a process with your credentials. For anyone running agents on sensitive data or real infrastructure, that boundary is the difference between a demo and something you can actually deploy.

What you get out of the box

Five reasoning patterns, selectable per agent: ReAct (think, act, observe), ReWOO (plan upfront and run steps in parallel, which Kite clocks at roughly 2x faster), Tree of Thoughts (explore multiple paths), Plan-Execute (decompose and replan on failure), and Reflective (generate, critique, improve).
Production safety primitives: a circuit breaker that stops cascading failures, a kill switch (per-agent or global) for when you need everything to stop now, and idempotency keyed on operation IDs so a retried action does not charge a customer twice.
Retrieval that is not a toy: HyDE, hybrid BM25 plus vector search, MMR deduplication, and reranking.
Prompt A/B testing with statistical confidence intervals on real traffic, because "the new prompt feels better" is not a deployment criterion.

What it looks like

The fastest path is the generator. Describe the agent, get a runnable file:

pip install kite-agent
export GROQ_API_KEY=your_key
kite generate "research assistant that searches and summarizes" --out agent.py
python agent.py

Or build one directly in Python and pick the reasoning pattern:

from kite import Kite

ai = Kite()
agent = ai.create_agent(name="Bot", agent_type="react")
result = await agent.run("user request")

Kite's own benchmarks put time to first agent at under a minute (versus roughly 30 minutes for LangChain and 20 for AutoGen in their tests) and cold startup around 50ms (versus ~2s and ~1s). Take the comparison as the authors' figures, not an audit, but the design intent is clear: get to a safe, running agent fast.

What we learned running agents in production

The model is about 10% of the work. The other 90% is tools, retries, guardrails, idempotency, and evaluation. A better model does not save you from a missing kill switch.
Most "agent failures" are IO failures in disguise. A flaky tool, a duplicated side effect, a partial write. Observability and idempotency beat another round of prompt tuning almost every time.
The untrusted-component framing is freeing, not limiting. Once the kernel is the thing that says yes or no, you stop being afraid to hand the agent real capabilities.

Why we open-sourced it

In a field full of black boxes, "you can read the code" is a differentiator, not a giveaway. We build production AI for regulated industries, and the way we earn a technical buyer's trust is by letting them inspect the hardest parts of our stack instead of taking a pitch on faith.

Kite is MIT licensed and lives at https://github.com/beevr-labs/Kite. Issues and PRs welcome. If you are building production-grade or compliance-bound AI and want a partner who ships the boring 90%, here is how we work.

What are you using to build agents in production, and what keeps breaking? Curious where Kite would and would not help.

Originally published on beevr.ai.

Your AI agent isn't HIPAA-compliant just because the model is good

Nguyen Thien — Tue, 30 Jun 2026 12:02:06 +0000

In 2026 everyone has shipped an AI agent. Far fewer have shipped one they could defend in an audit. Surveys keep finding the same gap: most security leaders are worried about AI-agent risk, and only a handful have actually put mature controls around it. Teams are deploying agents faster than they can govern them, and in healthcare, finance, or anywhere regulated, that's how a great demo becomes a reportable breach.

Here's the category error underneath it: a capable model is not a compliant system. You can point the best model in the world at protected health information (PHI) and still be wildly non-compliant. Compliance isn't a property of the model; it's a property of the architecture around it. (We've argued before that a good model doesn't make a tool HIPAA-compliant; with agents, the gap gets wider.)

An agent's compliance surface is bigger than a chatbot's

A chatbot reads and replies. An agent does things: it calls tools, queries databases, writes records, sends messages, and remembers across turns. Every one of those is a new place regulated data can leak or an unlogged action can happen:

Tool calls reach into systems that hold PHI, and each tool is a new data path that needs a BAA and least-privilege scoping.
Autonomous actions can change real state (book, cancel, message a patient). Anything affecting care can't be a black-box decision.
Memory and logs quietly persist PHI, often in places nobody put under a Business Associate Agreement.
Data egress to a hosted model provider is a transfer of PHI to a third party. No BAA with that provider, no compliance. Full stop.

The model is maybe 10% of the risk. The other 90% is everything the agent is wired to touch.

The governance checklist for agents on regulated data

If an agent goes near PHI, these aren't nice-to-haves; they're the difference between "audit-ready" and "liability":

BAA chain, including the model provider. Every service that processes PHI on your behalf (cloud, database, and the LLM API) needs a signed Business Associate Agreement before a single token flows. A consumer LLM endpoint with no BAA is an instant fail.
Minimize and mask PHI before the model sees it. Strip or tokenize identifiers at the boundary. The less PHI reaches the model, the smaller your breach blast radius.
Human-in-the-loop on anything affecting care. Measured accuracy plus a human sign-off, not autonomous decisions on treatment, eligibility, or anything clinical.
Tamper-evident audit logging of every action and tool call. Who, what, when, why, retained per HIPAA's six-year expectation. "What did the agent do at 2am?" must have an answer.
Least-privilege tools. Scope each tool to the minimum data and actions it needs. An agent that can read every record will eventually read the wrong one.
No training on PHI. Confirm contractually that your data isn't used to train the provider's models.
Measured, reported accuracy. Evaluation is part of the build, not a launch-day afterthought, and in regulated settings you have to be able to show it.

"But it's just RAG / it's read-only"

Doesn't matter. Read-only still means PHI egresses to wherever you embed and store it. RAG still puts patient data in a vector store and a prompt. The questions an auditor asks (where did the data go, who could see it, what's logged, who signed a BAA) don't care whether your agent writes anything. They care where the data went.

The takeaway

The winners in regulated AI aren't the teams with the flashiest agent. They're the teams whose agent can pass the audit, because the governance was designed in, not bolted on after the demo got applause. If your agent touches PHI (or card data, under PCI), build the framework first and let the model be the easy part.

That's how we build production AI for regulated industries: compliance by design, with the agent governance auditors actually ask for. If that's the bar your product has to clear, here's how we work.

If you're running agents on regulated data, what's your hardest governance problem right now? Logging, BAAs, or keeping humans in the loop without killing the UX?

We let AI coding agents into our codebase. The modular monolith won.

Nguyen Thien — Tue, 30 Jun 2026 11:58:48 +0000

For a decade, "microservices vs monolith" was an argument about human teams: Conway's Law, independent deploys, blast radius. In 2026 a new participant walked into the codebase and quietly changed the math: the AI coding agent.

We build software for a living. Our work is production systems for regulated industries, and we've spent the last year with agents (Claude Code, Cursor, the usual suspects) reading and writing real code alongside us. The pattern is consistent enough to say out loud: agents reason far better over a well-structured modular monolith than over a fleet of microservices. And we're not alone in moving that direction. The CNCF has reported a wave of teams consolidating services rather than splitting further.

Here's why, and where it still breaks.

Microservices were optimized for a constraint AI doesn't have

The original case for microservices was largely organizational: let many teams ship independently without stepping on each other. That's a real benefit for humans, at scale.

But an AI agent's bottleneck isn't team coordination. It's context. An agent is only as good as what it can see and hold at once. And microservices are, by design, an architecture of hidden context:

The logic for one user action is smeared across N repositories. To change a behavior, the agent has to discover, clone, and correlate code it can't see from where it started.
A function call became a network call. The agent can read a function and reason about it; it cannot "read" a flaky gRPC hop, a retry storm, or a partial failure between services.
Eventual consistency replaced transactions. The agent can't reason cleanly about state that's correct "soon."
There's no single stack trace. When something breaks, the truth is spread across logs in five services.

These are the same costs we wrote about in our trip to "microservices hell": the network tax, the observability tax, the eventual-consistency headache. For a human team they're an operational drag. For an AI agent they're a reasoning wall, because the information it needs to be correct is precisely the information the architecture hides.

A modular monolith is an agent's best-case environment

Flip every one of those and you get the modular monolith, with strong module boundaries inside a single deployable:

One repository = one context. The agent can load the whole picture: the call site, the function, the data model, the test, in one place. Repository-level understanding, the thing every 2026 agent is racing to do better, is trivial when there's one repository.
In-process calls. A call is a call: typed, traceable, refactorable. The agent can follow it and change both sides atomically.
Real transactions. State is consistent now, so the agent's mental model matches reality.
One stack trace. When a test fails, the agent sees the whole failure and can iterate, which is exactly how agentic coding loops work.

The modular monolith keeps the design benefit of microservices (clean separation, clear boundaries) while removing the operational fog that both humans and agents trip on. You get roughly 90% of the architectural benefit at about 10% of the cost, and now there's a second reason it matters: it's the difference between an agent that can safely refactor your system and one that flails across repos it can't hold in its head.

"But our agents will just handle the complexity"

The hope is that agents get good enough to manage distributed systems for us. Maybe, eventually. But today, handing an agent a microservices estate mostly multiplies the surface area where it can be confidently wrong, and distributed-systems bugs are the most expensive kind to be wrong about. Giving the agent a smaller, coherent world isn't a limitation; it's how you get trustworthy output. The teams getting the most out of agents in 2026 aren't the ones with the most services. They're the ones whose codebase an agent can actually understand.

When you should still split (the rule hasn't changed)

This isn't anti-microservices zealotry. Split a module into its own service when you have a clear, painful, obvious reason: a component with a wildly different scaling profile, a hard security or compliance isolation boundary, or a team that genuinely must deploy on its own cadence. That's a refactoring step you earn, not a starting point, and not a default you adopt because a conference talk said so. Start with the modular monolith; extract a service the day a specific module forces your hand, and not before.

The takeaway

Microservices solved a human-team problem and charged an operational tax to do it. AI agents don't have the problem, yet they pay the tax twice, because the architecture hides exactly the context they need to reason. If you're rebuilding your team around AI agents in 2026, the highest-leverage architectural decision you can make is to give them a codebase they can hold in one head: a modular monolith.

We build this way on purpose, on production systems where an agent (and a new senior engineer, and an auditor) can understand the whole thing. If that's the kind of software you need built, here's how we do it.

What's your experience letting agents loose on microservices vs a monolith? I'd genuinely like to hear where this breaks.