DEV Community: Nathan Tarbert

My open source project is brand new and already has contributors. Here's what I did.

Nathan Tarbert — Fri, 30 Oct 2026 16:03:47 +0000

In the spirit of Hacktoberfest, with it being the last day of October, I wanted to share my story about open source and building in public.

I'm a DevRel. In my day job, I help people who've never contributed to open source get their first code shipped. So when I started building answerLoops, an open source, self-hostable AI support tool, one thing bugged me. Was my own project actually easy to jump into?

What is answerLoops?

answerLoops turns your knowledge source into answers for your community. It's self-hostable, so you can run it on your own infrastructure with the AI provider you choose, or use the hosted app.

Here's the workflow:

A question comes in from a community channel like Discord, Slack, Discourse, GitHub, or website chat.
answerLoops searches your knowledge: your docs, files, GitHub repos, and Notion pages.
It drafts a reply with the sources attached.
A second AI agent checks the draft against those sources.
Your team approves the reply, or you turn on auto-reply for the questions that pass the check.
Useful resolutions are saved as knowledge, and knowledge gaps show what your docs are missing.

That workflow is why the labels below make sense. frontend work touches the dashboard where a team reviews and approves replies. backend work touches the pipeline and the channel integrations behind it.

Explore answerLoops on ⭐️ GitHub

The project is new, so the hard part right now is getting off the ground and getting people to find it. I posted about it on Reddit and X. It didn't bring in many stars. So I changed where I put my effort. Instead of trying to reach everyone, I focused on developers who want to build something and on making it easy for them to start.

Over the last week, developers started showing up. They sent pull requests, and I merged them. Some built something from an open issue. Others found a problem on their own and fixed it.

I can't prove any of this is cause and effect. I have a handful of data points, and some of them didn't pick up an issue at all. But I did set a few things up beforehand, and I think they're worth writing down for anyone starting out.

1. I labeled issues by skill, not just by type

At first my issues only had the usual labels: enhancement, bug, documentation. That tells a contributor what kind of change it is, but not whether it's for them.

I added two labels: frontend and backend. Right now I have 58 open issues, 41 tagged frontend and 33 tagged backend. Someone can click one label and see only the work that matches their skills, without reading all 58.

I also use good first issue and help wanted. good first issue is the one most people already know. The skill labels are the new part.

Most of the PRs I merged closed an issue with one of these labels, so they look like they're doing something. I'm still careful about how much I claim.

One side effect: only 8 good first issue tickets are open now. Labels only work while there's something behind them, so I'm writing more.

2. I wrote issues like specs

I'd have undersold this one if I'd only written about labels.

The issue my first contributor picked up was tagged frontend, good first issue, and help wanted. It was also written so that someone who had never seen the codebase could start. It had:

A Problem section: the data was already being collected and stored, but nothing in the UI showed it.
A Scope section: exactly what to show, where to start looking in the code, and what the wording should be.
A Not in this issue section: what to leave alone, so nobody drifts into a bigger project.
Acceptance criteria as a checklist.

It also said it was part of a larger tracking issue, so a contributor could see where it fit.

A vague issue like "show usage on the article page" leaves a newcomer guessing about scope, wording, and what "done" means. A scoped one lets them start. If I had to pick one thing to copy, it's this.

Every issue also ends with a link to the contributing guide, and it's now built into the Issues template.

3. I made the project easy to run

You can't contribute to something you can't start. I rewrote the README to be a short overview, and added a CONTRIBUTING guide plus issue forms for bugs, features, integrations, and docs, so new reports come in with the details I need.

The first version of the setup steps wasn't good enough. It ran the Docker path, then said "or run it natively," and I couldn't tell you which one to pick. If I was confused, a newcomer was too. I rewrote it as three steps: clone the app, set the values in one .env, and run it. Then I ran the native steps myself against a fresh database to make sure they work.

Contributors have already improved the docs from there, including a diagram of the install flow in the self-hosting quickstart.

4. Review was fast, and the PRs made it easy

The PRs came with a clear description of what changed, why, and how to try it. That made them easy to review, and I could merge quickly.

Fast feedback matters. A first-time contributor who waits two weeks for a reply rarely comes back.

5. I said thank you in public

The contributors are credited in the release notes and in the docs, and I thanked them publicly. Open source is mostly volunteers, so it's the least I can do. It also shows the next person what happens when they contribute.

I also posted on LinkedIn and X.

Thanks Aaqibhafeez Khan for the kind words

What I got wrong, or am not sure of

I don't know if the labels worked 100%. Nothing else about the project changed much, but I also posted about it in a few places, which brings people in on its own.
Not everyone took a labeled issue. Some contributors found a problem nobody had filed, and the labels can't explain that.
Return visits are the real test. What matters is whether people come back for a second PR.
The supply runs out. Contributors finish good first issue tickets quickly. Writing good ones is now a regular chore for me.

If you want to try this

Label issues by the skill needed, not just the type of change.
Write one issue as a spec: problem, scope, what's out of scope, and acceptance criteria.
Make sure someone can run the project, and test those steps yourself.
Review fast.
Thank people in public.

If you're new to open source and want help with a first PR, leave a comment or message me. I'm happy to walk you through it. The open issues are here: https://github.com/answerLoops/answerLoops/issues

And if you maintain a project: what got your first outside contributors to show up?

P.S. If you're reading this, starring ⭐️ the repo also really helps people find it :)

Thanks for reading!

Building an Open-Source Support Tool That Turns Your Docs into Reusable Knowledge

Nathan Tarbert — Tue, 20 Oct 2026 17:15:15 +0000

I spend a good part of my day working with the community at CopilotKit, answering questions in Discord, GitHub, and Slack, helping people get unstuck, and pointing them to the right resources.

I started building answerLoops to help me with that work. As it took shape, I added integrations for more platforms so other teams could use it in their communities too.

It’s open source, and I’m building it in public.

Explore answerLoops on ⭐️ GitHub

A big part of the work has been deciding how knowledge gets into the system. Some answers are in the docs. Others come out of a support conversation or are things someone on the team just knows.

For an agent to use those answers, the team needs a straightforward way to save them, review them, and keep them current. That’s what I’ve been building into the knowledge base.

Answering the question is only part of the work

A question comes in. You find the relevant documentation or resource, figure out how it applies to that person’s setup, and write a reply.

During that conversation, you might discover something the docs don’t cover. A missing setup step, a confusing default, or a workaround that deserves its own article.

You resolve the question, but that useful detail stays buried in the conversation. When someone else asks, the team has to find it again.

I want answerLoops to help with both parts: preparing a useful answer now and saving what the team learns for future questions.

What answerLoops does

answerLoops is an open-source AI support tool that brings questions from Discord, Slack, GitHub, Telegram, and other connected channels into one dashboard. It uses your knowledge base to help prepare answers.

For knowledge-based replies in the ticket pipeline, a Mastra agent generates a draft and a separate agent scores its confidence and whether it fully answers the question. Automatic replies are off by default. When enabled, answers that meet the configured criteria can be sent automatically; other drafts remain available for human review.

There’s also an embeddable website chat widget built with CopilotKit and connected to a Mastra support agent. Visitors can ask questions directly, with published knowledge-base articles supplied as reference material.

The widget supports richer responses, including step-by-step guides, quick replies, callouts, link cards, and contact options.

But the quality of those answers depends on the information available to the agent. That’s why much of the recent work has been on the knowledge base.

Add the answer that isn’t in your docs

Sometimes you don’t need to import a documentation site. You just need to write down something the agent should know.

An owner or admin can open Knowledge Base → Manage and use Write an answer by hand:

Enter a question or title.
Write the answer or context.
Click Add to knowledge base.

For example, a customer might ask whether changing a configuration requires a restart. Someone on your team knows the answer, but it isn’t documented anywhere.

The article is published and indexed when it’s saved, making it available for subsequent questions. There’s no draft step in this form, so the answer should be suitable for customers to read.

Adding an article doesn’t retrain the model. It gives the agent another reference to retrieve when a relevant question comes in.

Articles added this way appear under Added by hand in the Knowledge coverage tab.

It’s a small feature, but it gives the person with the answer a direct way to improve what the agent knows.

Bring in the knowledge you already have

You can also populate the knowledge base from existing content:

Documentation URLs: import a page or crawl a documentation site.
Files: upload PDF, DOCX, Markdown, text, or CSV files.
GitHub: sync Markdown and MDX files, with optional syncs when changes are pushed to the default branch.
Notion: connect pages and databases your team wants to use.

Notion content imports unpublished. Your team can inspect it before making it available for customer-facing answers, and that publishing choice is preserved across syncs.

The manual-entry form sits alongside these sources. If an answer already exists in your docs, import it. If it only exists in someone’s head, write it down.

Turn a resolved ticket into reusable knowledge

Closing a ticket helps the person who asked. Turning that resolution into a knowledge-base article makes the explanation available for future questions.

The Promote to KB action lets an owner or admin turn that ticket’s question and answer into a knowledge-base article.

Before promoting it, check that the answer applies beyond the original conversation. Remove account-specific details and make the explanation useful to someone encountering the same problem later.

This matters for the website widget in particular. Its retrieved reference material comes from published KB articles, rather than raw resolved tickets.

Promoting an answer gives it a place in the shared knowledge base where the widget can find it.

Let customer questions help you decide what to write

You won’t know every gap in your documentation ahead of time.

The Review tab captures questions that weren’t covered by the available knowledge. On hosted plans, this queue is available on Pro and above.

A usable draft can come along as a starting point. If there isn’t one, the item is marked No usable answer, and someone can write it.

Owners and admins can edit the question and answer, then choose Approve and add to knowledge base. If the item shouldn’t become an article, they can reject it instead.

Nothing in the queue becomes searchable customer-facing knowledge until it’s approved.

When the same question comes in again, its counter increases instead of creating another copy. The most-asked questions appear first.

If several people ask about the same setup step, that’s a useful signal about what your knowledge base is missing. The queue gives your team a question to work from and a place to review the answer before publishing it.

Go from a knowledge gap to a new article

The Knowledge Gaps page provides another view of where support needs attention.

It surfaces tickets with low-confidence answers, tickets that need a person, and resolved questions without a covering KB article.

Repeated questions are grouped with an Asked N times badge, so you can see recurring topics without reading every ticket separately.

The + KB action opens the manual-entry form with the ticket’s question and any existing answer filled in. Review the text, add the article, and it’s linked back to the ticket to close that gap.

You don’t have to leave the question behind and start a blank document somewhere else.

Check what the agent can actually find

Importing a document doesn’t tell you whether it will help with a particular question.

The Knowledge coverage tab shows articles grouped by source, including whether they’re live, unpublished, or not searchable.

There’s also a Try a customer question field. It runs the same lookup the website widget uses and shows which articles match—or that nothing covers the question.

After adding an answer, try the original customer question and a few variations. Does the lookup find the article you just wrote? If it doesn’t, you have something concrete to investigate before judging the generated reply.

This checks retrieval, not whether every generated reply will be correct. You still need to review the answers themselves. But it gives you a way to investigate whether the intended information is being found.

The KB is the source of product knowledge your team maintains for the agent. If no article matches, the assistant can fall back to general knowledge, which may not fit your product. Finding those gaps and adding the right material is part of maintaining it.

See which articles are being used

answerLoops also tracks article usage.

It counts when an article is supplied as context for an answer that is actually produced, including website replies and ticket drafts.

The distinction matters: this means the article was given to the agent, not necessarily that the final reply quoted it.

Searches and simulations don’t increase the count.

Together with the coverage view and repeated-question counts, this helps you understand what information is being retrieved and where more work might be useful.

Where CopilotKit and Mastra fit

I work in DevRel at CopilotKit, so part of building answerLoops is putting the tools I work with into a product and sharing what I learn.

Mastra runs the agents behind the support drafts and website conversation, including the chat agent’s thread memory.

CopilotKit provides the foundation for the custom widget interface. The application connects that interface to the agent and supplies the relevant knowledge-base context.

The product also has its own workflows around those pieces: importing sources, reviewing unanswered questions, publishing articles, and handling staff actions on tickets.

Those workflows are where the team gets to improve the information the agent uses. Someone can spot a missing answer, write it, publish it, and check whether a future question retrieves it.

That’s become a much bigger part of answerLoops as I’ve kept building.

Try it, I would love your feedback

I started this to help with my own community work. I’m sharing it so other developers and support teams can try it in theirs.

The code and setup instructions are on GitHub. You can explore how retrieval, the review queue, and the integrations work, or run answerLoops yourself. The knowledge-base documentation walks through the workflows in this article.

If it looks useful, give the repo a ⭐️. If you try it, tell me what worked and what got in your way.

New to contributing to open source? Reach out—I’d be happy to help you find a place to start.

Where does your team keep the useful answers that haven’t made it into the docs yet?

How Microsoft Agent Framework + AG-UI Enable Agentic UX & Generative UI

Nathan Tarbert — Thu, 20 Nov 2025 15:13:16 +0000

Building with the Microsoft Agent Framework + AG-UI

Microsoft’s Agent Framework (MAF) is an open-source agent framework that has recently emerged, offering exceptional ways to build agents and multi-step workflows in .NET or Python. Paired with AG-UI, the frontend/runtime layer that enables those agents to appear in your app with a clean UI, streaming responses, and shared state, etc., delivers a seamless agentic experience.

The integration between the two is simple but powerful: MAF handles the reasoning and tool-use, and AG-UI bridges the interactions between the agent and the users.

Microsoft Agent Framework (MAF) and AG-UI together offer a clean separation:

MAF handles the agent’s intelligence, workflows, memory, and tool use.
AG-UI is the open protocol that standardizes how agents communicate with user interfaces.

Once an agent speaks AG-UI, it becomes immediately compatible with any AG-UI-aware frontend, including Microsoft’s own Blazor client and CopilotKit.

This combination is what turns MAF agents from “backend processes” into interactive, stateful, user-facing agents.

What the Microsoft Agent Framework Provides

MAF provides the core building blocks:

Agents that call models, use tools, and keep state across turns.
Workflows for multi-step or multi-agent processes.
Model and memory providers so your agents can store data or thread context.

Check out MAF GitHub ⭐️

It’s practical if you want to move past “chat completion” and give the model structure, state, and the ability to act.

What AG-UI Adds to the Picture

AG-UI is the open protocol that defines how an agent communicates with a user interface.

It standardizes things like:

Streaming messages
State updates
Tool invocations
UI events
Multi-agent routing
Interruptions / tool-progress events
Frontend → agent actions

This removes the need to design your own transport, your own formatting, your own event system, or your own UI message schema.

Instead of every framework inventing its own UI contract, AG-UI is the shared layer they converge on.

Check out AG-UI's GitHub ⭐️

Microsoft Agent Framework + AG-UI

1. MAF agents become UI-ready out of the box

No additional custom wiring.
No custom WebSockets.
No bespoke JSON formats.

The agent speaks AG-UI, which removes any additional complexities.

2. Multi-step workflows can surface naturally in UI

Because AG-UI supports state sync and streaming, a MAF workflow can show:

intermediate states
partial outputs
tool progress
agent-to-agent handoffs
moments where the agent needs user input

This is critical for user trust and usability.

3. Typed state becomes visible to the user

MAF agents often maintain a structured state (objects, lists, workflow context).

AG-UI transports this state to the frontend, where it can drive live UI components.

4. Use of tools

AG-UI can show:

When a tool was invoked
What parameters were used
What the tool returned

This is a major improvement over hidden function-calling flows.

5. Use any AG-UI-compatible frontend

Once your MAF agent speaks AG-UI, you can plug it into:

CopilotKit
Microsoft Blazor
Terminal Client
Kotlin SDK (mobile, JVM)

This gives the agent a portable, future-proof interface layer.

Why This Matters for Developers

A complete agent loop

Agent → protocol → frontend → user → agent

No custom engineering required.

A more interpretable agent

With streaming, intermediate states, and exposed tool use, you can debug and trust the agent in a way plain chat completions don’t allow.

This allows a path to build real applications

SaaS copilots
Co-creation copilots
automation agents

All while retaining clear structure and maintainability.

Additionally, the developer doesn't need to reinvent the wheel.

--> MAF handles reasoning + tools.

--> AG-UI handles communication + events.

--> The user is now able to collaborate with the agent in real time.

The stack is clean.

Summary

Microsoft Agent Framework gives you an agent with: tools, workflows, state, orchestration, and model thinking.

AG-UI gives that agent a standardized way to interact with the user, whether on mobile or desktop.

Together, they let you build agents that aren’t constrained to the backend, but usable, visible, and connected to real applications.

To stay up to date, please follow CopilotKit on Twitter and join the Discord community.

Vibe Code an Agentic App in Under 7 Minutes

Nathan Tarbert — Tue, 26 Aug 2025 11:13:18 +0000

Building agentic applications is powerful-but the complexity level starts to rise.

Things like managing context, wiring actions, and giving agents reliable access to documentation can eat up time before you even get to shipping features.

Not to worry, that's where the new Vibe-Coding Server comes in.

What is the Vibe-Coding Server?

The Vibe-Coding Server, built on MCP (Model Context Protocol), gives coding agents structured access to both CopilotKit documentation and actual code examples from the repos.

Instead of dumping entire pages or manually tagging docs every time, the server automatically fetches only the relevant snippets. This means:

Faster responses, more efficient development
Lower token usage
Better context for your agents

With the Vibe-Coding Server in place, you can layer in agentic features

Together, they move your agent from being conversational → operational.

See it in action here and for better video quality, on YouTube:

I recorded a walkthrough of the Vibe-Coding Server in action- including generated code examples, actions, readables, and the drop-in chat component, so you can see how everything fits together.

Would love to hear what you're connecting MCP to!

Follow CopilotKit on Twitter and say hi, and if you'd like to build something cool, join our Discord.

Two New Ways to Build with AG-UI: LlamaIndex and Agno

Nathan Tarbert — Thu, 19 Jun 2025 14:07:18 +0000

TL;DR

It’s been a huge month for AG-UI, the open protocol for interactive AI agents. Today, we’re expanding support with two new frameworks:

LlamaIndex — enabling retrieval-augmented agents to connect with users in real-time
Agno — bringing intuitive multi-agent workflows into the AG-UI ecosystem

Developers now have even more power to build rich, interactive agent experiences.

🚀 AG-UI Hits a Major Milestone

One month after launch, AG-UI continues to grow and evolve. Today’s update brings two new integrations that expand what's possible with agentic interfaces:

Agno: A modular agent orchestration framework now compatible with AG-UI, so you can expose your Agno agents to users through real-time interfaces.
LlamaIndex: Build production agents that can find information, synthesize insights, generate reports, and take actions over the most complex enterprise data.

These additions make it easier than ever to build high-quality user-facing AI with your favorite agent frameworks.

What Is AG-UI?

AG-UI (Agent-User Interaction Protocol) is a lightweight spec that connects backend AI agents with frontend applications. It turns agents into live, interactive participants inside your UI, not just silent executors behind an API.

It’s the difference between a black box backend and a fully visible, controllable copilot.

Think: Cursor vs. Devin.

Why It Matters

Today’s agents are often disconnected from the user. If you want real-time interaction, you’re left wiring up:

Streaming outputs
Tool invocation feedback
Shared session state
UI rendering logic
Messaging pipelines

AG-UI solves this by giving agents and apps a shared event protocol, so they can speak the same language out of the box.

How It Works

AG-UI defines 16+ event types that power live agent behavior, from tool calls to token streaming to UI state updates.

Agents can either:

Emit AG-UI events directly
Or use an adapter to convert outputs into AG-UI format

Clients subscribe to an event stream (via SSE or WebSockets), render the events live, and send back user input or control signals.

This unlocks dynamic, real-time interaction between agents and users.

Adoption & Growth

In less than 30 days, AG-UI has gained serious traction:

Integrated with: LangChain, CrewAI, Mastra, AG2, Agno, LlamaIndex
In progress: AWS, A2A, ADK, AgentOps, Human Layer (Slack)
3,700+ GitHub stars
Thousands of developers are building interactive agents

Build with AG-UI

Getting started is fast:

npx create-ag-ui-app

Let me know what you are building!

Follow CopilotKit on Twitter and say hi, and join our active Discord Community!

Introducing AG-UI: The Protocol Where Agents Meet Users

Nathan Tarbert — Tue, 13 May 2025 14:44:13 +0000

I'm thrilled to announce AG-UI, the Agent-User Interaction Protocol, a streamlined bridge connecting AI agents to real-world applications.

This brand new protocol is brought to you by CopilotKit

Check out AG-UI's GitHub ⭐️

What is AG-UI?

AG-UI is an open, lightweight protocol that streams a single sequence of JSON events over standard HTTP or an optional binary channel. These events—messages, tool calls, state patches, lifecycle signals—flow seamlessly between your agent backend and front-end interface, maintaining perfect real-time synchronization.

Get started in minutes using our TypeScript or Python SDK with any agent backend (OpenAI, Ollama, LangGraph, or custom code). Visit docs.ag-ui.com for the specification, quick-start guide, and interactive playground.

Agent-User Interaction

Today’s AI Agent ecosystem is maturing. Agents are going from interesting viral demos to actual production use, including by some of the biggest enterprises in the world.

However, the ecosystem has largely focused on backend automation, processes that run independently with limited user interaction. Workflows that are set off, or happen automatically, whose output is then used.

Common use-cases include data migration, research and summarization, form-filling, etc.

Repeatable and simple workflows, where accuracy can be ensured, or where 80% accuracy is good enough.

These have already been big productivity boosters. Automating time-consuming and tedious tasks.

Where Agents Meet Users

Coding tools (Devin vs. Cursor)

Throughout the adoption of generative AI, coding tools have been canneries in the coal mine, and Cursor is the best example of a user-interactive agent. An AI agent that works alongside users, in a shared workspace.

This contrasts with Devin, which was the promise of a fully autonomous agent that automates high-level work.

For many of the most important use-cases, Agents are helpful if they can work alongside users. This means users can see what the agent is doing, can co-work on the same output, and easily iterate together in a shared workspace.

The Challenges of Building a User-Interactive Agent

Creating these collaborative experiences presents significant technical challenges:

Real-time streaming: LLMs produce tokens incrementally; UIs need them instantly without blocking on the full response.
Tool orchestration: Modern agents call functions, run code, hit APIs. The UI must show progress and results, sometimes ask for human approval, and then resume the run—all without losing context.
Shared mutable state: Agents often generate plans, tables, or code folders that evolve step-by-step. Shipping entire blobs each time wastes bandwidth; sending diffs demands a clear schema.
Concurrency & cancellation: A user might fire off multiple queries, stop one mid-flight, or switch threads. The backend and front-end need thread IDs, run IDs, and an orderly shutdown path.
Security boundaries: Streaming arbitrary data over WebSockets is easy until you need CORS, auth tokens, and audit logs that an enterprise will sign off on.
Framework sprawl: LangChain, CrewAI, Mastra, AG2, home-grown scripts—all speak slightly different dialects. Without a standard, every UI must reinvent adapters and edge-case handling.

The AG-UI Solution

AG-UI addresses these challenges through a simple yet powerful approach:

Your client makes a single POST to the agent endpoint, then listens to a unified event stream. Each event has a type(e.g., TEXT_MESSAGE_CONTENT, TOOL_CALL_START, STATE_DELTA), and minimal payload. Agents emit events as they occur, and UIs respond appropriately—displaying partial text, rendering visualizations when tools complete, or updating interfaces when state changes.

Built on standard HTTP, AG-UI integrates smoothly with existing infrastructure while offering an optional binary serializer for performance-critical applications.

What This Enables

Please like and follow

AG-UI establishes a consistent contract between agents and interfaces, eliminating custom WebSocket formats and text parsing hacks. With this unified protocol:

Components become interchangeable: Use CopilotKit's React components with any AG-UI source
Backend flexibility: Switch between cloud and local models without UI changes
Multi-agent coordination: Orchestrate specialized agents through a single interface
Enhanced development: Build faster with richer experiences and zero vendor lock-in

AG-UI isn't just a technical specification—it's the foundation for the next generation of AI-enhanced applications where humans and agents seamlessly collaborate.

Please check out the Getting Started docs, and I look forward to you trying it out.

Interested in connecting with other AI developers?
Join the AG-UI Discord and join the AI developer community: https://go.copilotkit.ai/AG-UI-Discord

Follow CopilotKit on Twitter and say hi, and if you'd like to build something cool.

Turn Your React App Into an MCP Client in Minutes

Nathan Tarbert — Tue, 06 May 2025 15:45:43 +0000

I'm on the CopilotKit team, and I'm excited to announce we've just added built-in support for MCP. The update went live today.

For those unfamiliar, CopilotKit is a self-hostable, full-stack framework for building user interactive agents and copilots.. Our focus is on allowing your agents to take control of your application (by human approval), communicate what it's doing, and generate a completely custom UI for the user.

Check out CopilotKit's GitHub ⭐️

What’s an MCP Client?

It’s a web-based, client (React in this case) that lets you chat with any MCP server in your own app. All you need is a URL from Composio to get started.

MCP lets you connect LLMs to external tools in a standardized way. Now you can use a chat interface to talk to any MCP-compatible server, right from your React app, with no agent framework required.

Quickstart:

With one command, you can start talking to MCP servers locally, from your own Next.js app.

 copilotkit@latest init -m MCP

What we built:

To show it off, I connected a simple self-hosted ToDo app to two platforms using MCP:

Asana – Send blog ideas as tasks, assign them to myself, and set due dates.

Typefully – Pull blog titles and save them as draft tweets.

Stack:

UI: CopilotKit

MCP servers: Composio

Framework: Next.js

Agentic framework: None

The code is open source, and contributions are welcome.

GitHub: https://github.com/CopilotKit/copilotkit-mcp-demo

Docs: https://docs.copilotkit.ai/guides/model-context-protocol

Video demo: https://x.com/CopilotKit/status/1917976289547522074

Twitter Announcement: https://x.com/CopilotKit/status/1917976289547522074

Would love to hear what you're connecting MCP to!

Follow CopilotKit on Twitter and say hi, and if you'd like to build something cool, join our Discord.

How To Use an MCP React Client with Multiple AI Agents

Nathan Tarbert — Tue, 22 Apr 2025 15:13:34 +0000

Hey everyone👋

I run the community at CopilotKit, a free and open-source framework for building intelligent companions and in-app infrastructure.🤔

Think about it this way:🧐

CopilotKit allows your agents to control your application, communicate what its doing, and generate completely custom UI.

Check out CopilotKit's GitHub ⭐️

What is MCP?

I recorded this quick demo to show just one example of what you can build with the (Open Multi-Agent Canvas with MCP.

It looks like a sandbox, but it's so much more. With MCP, agents can work together and take real actions, like sending messages to Slack, triggering APIs, or updating your app—all in one interface. Before, doing this kind of multi-agent coordination was messy. Now it’s much simpler.

Resources:

CopilotKit GitHub Repo

Follow CopilotKit on Twitter and say hi, and if you'd like to build something cool, join our Discord.

Build Full-Stack AI Agents with Custom React Components (CopilotKit + CrewAI)

Nathan Tarbert — Fri, 28 Mar 2025 14:35:02 +0000

Hey everyone👋

I manage the community at CopilotKit, a free and open-source framework for building intelligent companions and, in-app infrastructure.🤔

Think about it like this:🧐 CopilotKit allows your agents to take control of your application, communicate what its doing, and generate completely custom UI.

Check out CopilotKit's GitHub ⭐️

Build Full-Stack Agents

Atai, the Co-Founder and CEO of CopilotKit produced this video to showcase how simple it is to build agents using CrewAI and bring them into your app in easy-to-understand steps.

Agentic Apps

A new wave of Agent-Native apps has emerged - such as Replit's AI Agent, Vercel's new v0, and ChatGPT's Canvas.

These apps deeply integrate an AI agent into a native application, allowing for deep human/AI collaboration and human-in-the-loop flows.

In this video, we will show you how to add an agent to your app in just a few minutes.

Resources:

CopilotKit GitHub Repo

Follow CopilotKit on Twitter and say hi, and if you'd like to build something cool, join our Discord.

Timestamps if you want to jump around:

00:00 CoAgents intro with CrewAI
00:22 Use the new CLI tool to add Crews to your React app
02:09 Created App with Shared agent state
03:50 React component to render the agent streaming
06:04 Agentic Generative UI
06:25 The CrewAI feature viewer demo

How to Build a Full Stack Agentic Researcher in 5 Minutes ⚡️⚡️

Nathan Tarbert — Wed, 26 Feb 2025 18:59:07 +0000

Hey everyone👋

I'm a DevRel and manage our community at CopilotKit, a free and open-source framework for building intelligent companions and, in-app infrastructure.🤔

Think about it like this:🧐 you can embed a chat interface similar to ChatGPT that doesn't just respond but actively takes actions within your app's frontend functions (Client Side) based on LLM outputs.

Agentic Apps

A new wave of Agent-Native apps has emerged - such as Replit's AI Agent, Vercel's new v0, and ChatGPT's Canvas.

These apps deeply integrate an AI agent into a native application, allowing for deep human/AI collaboration and human-in-the-loop flows.

In this video, we will show you how to add an agent to your app in just a few minutes.

Resources:

CopilotKit GitHub Repo

Follow CopilotKit on Twitter and say hi, and if you'd like to build something cool, join our Discord.

Timestamps if you want to jump around:

00:00 CoAgents intro
01:51 Add agent chat to the app
03:35 Share State between the Agent<>App
05:20 Stream agent state
07:04 Agentic GenUI
08:25 Human-in-the-Loop

Bringing a DeepSeek R1 LangGraph Agent Into The Real World Using CopilotKit

Nathan Tarbert — Wed, 05 Feb 2025 21:52:00 +0000

Hey everyone!

I'm a DevRel at CopilotKit, an open-source framework for agentic UI and in-app agents.

I wanted to share a video we produced to show how easy it is to give your app AI superpowers in just minutes.

The DeepSeek R1 LangGraph agent demo is powered by one simple hook, the useCoAgent hook (https://docs.copilotkit.ai/reference/....
Then, viola, you are cooking with gas so to speak!

Resources:

Follow CopilotKit on Twitter and say hi, and if you'd like to build something cool, join our Discord.

Build Your Own RAG Copilot with Anthropic, Pinecone, & CopilotKit

Nathan Tarbert — Wed, 29 Jan 2025 15:09:59 +0000

TL;DR

In this tutorial, we’ll walk you through building an AI-powered RAG Copilot step by step for your product Knowledge Base using the Anthropic AI API, Pinecone API, and CopilotKit🪁.

Here’s what we’ll cover:

Building a simple product knowledge base using Next.js
Adding CopilotKit UI components to your app client along with CopilotKit’s API endpoint.
Integrating Pinecone API to create searchable indexes for your knowledge base articles.

The result is a fully functioning RAG Knowledge Base application using CopilotKit:

What is CopilotKit

CopilotKit is the leading open-source framework for integrating production-ready AI-powered copilots into your applications. It provides a feature-rich SDK that supports various AI copilot use cases, including context awareness, copilot actions, and generative UIs.

This means you can focus on defining your copilot's role, rather than getting bogged down in the technicalities of building one from scratch or dealing with complex integrations.

Check out CopilotKit's GitHub ⭐️

Prerequisites

Before we get started, here are a few things you’ll need:

Familiarity with building web apps using React.js. A quick note—you’ll also need some knowledge of TypeScript, as we’ll be using it for this project.
Ensure Node.js >20 is installed on your system. If not, you can download and install it from the official Node.js website.

Once you’ve covered these, we’ll set up the development environment we’ll be working in.

Here’s a quick preview of what we’ll be building:

Setting Up the Project

To get started, run these commands to create a new directory for the project, and scaffold the Next.js application boilerplate source files and folders:

mkdir product-knowledge-base && cd product-knowledge-base
npx create-next-app product-knowledge-base

Follow the setup prompts. You can select as shown below (adjust based on your project requirements).

Once the project is created, navigate to the project directory, and verify everything works by running the development server:

cd product-knowledge-base
npm run dev

At this stage, your app should be running locally at http://localhost:3000.

Next, let’s install the necessary dependencies for this project. These include:

Mantine UI.
CopilotKit Packages.
Pinecone SDK.
Anthropic AI SDK.
Axios.

Run the following command to install them:

yarn add @anthropic-ai/sdk @mantine/core @mantine/hooks @copilotkit/react-core @copilotkit/react-ui @copilotkit/runtime lucide-react axios @pinecone-database/pinecone

Now, let’s set up the file structure for the project. Here is an overview of the main files and directories we’ll create:

src/app/ui/service/index.ts: To handle API calls to the backend to fetch dummy posts.
src/app/ui/components/KnowledgeBase.tsx: The main UI component for the knowledge base.
src/app/lib/types/post.ts:
src/app/lib/data/data.ts: dummy post data for the knowledge base.
src/app/api/copilotkit/route.ts: CopilotKit API endpoint.
src/app/api/posts/route.ts: dummy posts API endpoint.

Here’s how your project structure will look:

product-knowledge-base/
├── src/
│   ├── app/
│   │   ├── ui/
│   │   │   ├── service/
│   │   │   │   └── index.ts
│   │   │   ├── components/
│   │   │   │   └── KnowledgeBase.tsx
│   │   ├── lib/
│   │   │   ├── types/
│   │   │   │   └── post.ts
│   │   │   ├── data/
│   │   │   │   └── data.ts
│   │   ├── api/
│   │   │   ├── copilotkit/
│   │   │   │   └── route.ts
│   │   │   ├── posts/
│   │   │   │   └── route.ts

With this setup, you now have a working development environment for this tutorial.

Building the Knowledge Base Frontend

First, import the CopilotKit and Mantine UI providers, then wrap your entire app with them so they're available globally. Here's how you can update your layout.tsx file:

import { MantineProvider } from "@mantine/core";

import "@mantine/core/styles.css";
import "@copilotkit/react-ui/styles.css";

import { CopilotKit } from "@copilotkit/react-core";

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body>
        <CopilotKit runtimeUrl="/api/copilotkit">
          <MantineProvider>{children}</MantineProvider>
        </CopilotKit>
      </body>
    </html>
  );
}

When wrapping the app with these providers, remember to pass the runtimeUrl="<endpoint-url>" prop to the CopilotKit provider.

Designing the Knowledge Base Component

In this section, we’ll go over the code you need to build the knowledge base component. Let's start by defining the Post interface. Add the following code in your src/app/lib/types/post.ts:

export interface Post {
  id: number;
  title: string;
  summary: string;
  content: string;
  category: string;
  createdAt: string;
}

Next, navigate to the src/app/ui/service/index.ts file, and add the following code to handle API requests to fetch posts from the app’s backend:

import axios from 'axios';
import { Post } from '@/app/lib/types/post';

const API_BASE_URL = process.env.NEXT_PUBLIC_API_BASE_URL 

export const fetchPosts = async (): Promise<Post[]> => {
  const response = await axios.get(`${API_BASE_URL}/api/posts`);
  return response.data;
};

Let's create a .env file in the root directory of your project, and add the following base URL.

NEXT_PUBLIC_API_BASE_URL='http://localhost:3000'

Now, let’s create the Knowledge Base UI component. Inside the src/app/ui/components/KnowledgeBase.tsx, start by adding the following imports:

"use client"

import { useState, useEffect } from "react";
import {
  Container,
  Title,
  Grid,
  Card,
  Text,
  Badge,
  Group,
  Stack,
  Box,
  Modal,
  List,
} from "@mantine/core";
import { BookOpen } from "lucide-react";
import { Post } from "@/app/lib/types/post";
import { fetchPosts } from "@/app/ui/service";

Next, define the KnowledgeBase functional component and initialize the following states:

export function KnowledgeBase() {
  const [posts, setPosts] = useState<Post[]>([]);
  const [loading, setLoading] = useState(true);
  const [selectedPost, setSelectedPost] = useState<Post | null>(null);

  if (loading) {
    return <Text>Loading...</Text>;
  }

  return (
    <Container size="md" py="xl" ml="xl">
      <Stack gap="xl">
        <Group justify="center" align="center">
          <BookOpen size={32} />
          <Title order={1}>CopilotKit Product Knowledge Base</Title>
        </Group>
      </Stack>
    </Container>
  );
}

Now, let’s define a function to fetch the list of posts from the API:

useEffect(() => {
  const loadPosts = async () => {
    try {
      const data = await fetchPosts();
      setPosts(data);
    } catch (error) {
      console.error("Error loading posts:", error);
    } finally {
      setLoading(false);
    }
  };

  loadPosts();
}, []);

To display the posts fetched from the app’s backend, add the following code. We will render the list of posts in a grid layout with cards:

{/* Display posts */}
<Grid>
  {posts.map((post) => (
    <Grid.Col key={post.id} span={{ base: 12, sm: 6, md: 4 }}>
      <Card
        shadow="sm"
        padding="lg"
        radius="md"
        withBorder
        onClick={() => setSelectedPost(post)}
        style={{ cursor: "pointer" }}
      >
        <Stack gap="md">
          <Title order={3}>{post.title}</Title>
          <Badge color="blue" variant="light">
            {post.category}
          </Badge>
          <Text size="sm" c="dimmed">
            {post.summary}
          </Text>
          <Text size="xs" c="dimmed">
            Posted on: {new Date(post.createdAt).toLocaleDateString()}
          </Text>
        </Stack>
      </Card>
    </Grid.Col>
  ))}
</Grid>

To show the content of a single post, in this case, we’ll keep things straightforward by displaying dummy content in a modal component when an article card is clicked. To do that, add the following code:

{/* Modal for displaying selected post */}
{selectedPost && (
  <Modal
    opened={!!selectedPost}
    onClose={() => setSelectedPost(null)}
    title={selectedPost.title}
    centered
    size="xl"
  >
    <Stack gap="md">
      <List>
        {selectedPost.content
          .split("")
          .filter((item) => item.trim() !== "")
          .map((item, index) => (
            <List.Item key={index}>{item}</List.Item>
          ))}
      </List>
    </Stack>
  </Modal>
)}

Next, define the following function to update the selected post state when users click on the post’s card.

  const handlePostClick = (post: Post) => {
    setSelectedPost(post);
  };

Finally, to render this component in the browser, import it in your src/app/page.tsx file with the following code (make sure to delete all the boilerplate Next.js code):

import KnowledgeBase from "@/app/ui/components/KnowledgeBase";

export default function Home() {
  return (
    <div>
      <KnowledgeBase />
    </div>
  );
}

Adding CopilotKit UI Components

The next step involves adding CopilotKit UI components into the knowledge base interface. CopilotKit’s React SDK provides neatly designed and easily customizable UI components. These include sidebars, pop-ups, text areas, and a headless UI component. For this example, we will use the `CopilotSidebar` component to render an in-app chatbot interface.

To add CopilotKit’s UI sidebar component, in your src/app/ui/components/KnowledgeBase.tsx, add the following import:

import { CopilotSidebar } from "@copilotkit/react-ui";

Once imported, add the component in the JSX return statement:

<Group justify="center" style={{ width: "100%" }}>
  <Box style={{ flex: 1, maxWidth: "350px" }}>
    <CopilotSidebar
      instructions="Help the user get the right knowledge base articles for their query"
      labels={{
        initial: "Welcome! Describe the query you need assistance with.",
      }}
      defaultOpen={true}
      clickOutsideToClose={false}
    />
  </Box>
</Group>

The component accepts various props, including instructions, labels, defaultOpen, and clickOutsideToClose. Importantly, the instructions prop allows you to provide additional context to help the underlying Copilot AI LLM better understand and respond to user queries.

Using CopilotKit Hooks for AI Actions

The React CopilotKit SDK also provides a set of useful hooks that enable you to define custom actions for your app’s AI Copilot. For this example, we will use the useCopilotAction hook to define the intended action, that is, to retrieve knowledge base articles based on a user query.

To do that, start by importing the useCopilotAction hook in your KnowledgeBase component file as follows:

import { useCopilotAction } from "@copilotkit/react-core";

After importing, you can initialize the hook, and specify the action you want the copilot to perform. In this case, we’ll define an action named “FetchKnowledgebaseArticles” to retrieve relevant articles based on the supplied user query. Let's write the code for it:

useCopilotAction({
  name: "FetchKnowledgebaseArticles",
  description: "Fetch relevant knowledge base articles based on a user query",
  parameters: [
    {
      name: "query",
      type: "string",
      description: "User query for the knowledge base",
      required: true,
    },
  ],
  render: "Getting relevant answers to your query...",
});

This action setup includes several important elements. The name attribute provides a unique identifier for the action, while the description explains its purpose and when it should be used.

Additionally, the parameters array defines the inputs required for the action, such as the user’s query in this case. And lastly, the render property allows you to specify what will be displayed while the action is being executed. For this example, we’ll display a simple status message to keep the user informed about the ongoing process.

Integrating the App’s Backend

To complete the entire app’s workflow, let’s build the backend by adding endpoints for fetching posts, integrating CopilotKit functionality, and the Pinecone API to create searchable indexes for the knowledge base articles.

To do that, first, go to this GitHub repository file containing the dummy posts data, copy, and paste it into your local src/app/lib/data/data.ts file.

Next, in the src/app/api/posts/route.ts file, add the following code to set up the dummy posts API endpoint:

import { NextResponse } from 'next/server';
import { posts } from '@/app/lib/data/data';

export async function GET() {
  return NextResponse.json(posts);
}

At this point, start your dev server and head over to your app’s localhost URL. You should see the list of posts displayed, along with the CopilotKit sidebar component.

Going back to the main intent of the guide, which is, integrating an AI Copilot for product knowledge bases. Typically, most product knowledge bases are loaded with all sorts of content—blog articles, FAQs, internal SOPs, API documentation, and more. That’s a lot more than the three dummy posts we’re working with in this example.

Normally, these knowledge bases have integrated Algolia Search API to let users quickly search through resources. Now for the AI copilot, we want to go beyond just “search-show”.Essentially, we want to take advantage of LLMs’ ability to understand natural language to implement “conversational-like” search functionality for knowledge bases’ resources.

Instead of simply returning static search results, the Copilot will allow users to “chat” about the resources, ask follow-up questions, and get answers in a much more user-friendly way. This is arguably more intuitive.

To make this happen, we need to create LLM-searchable indexes—essentially, data sources that the AI can query to fetch the right information. For this, we’ll use Pinecone's vector database API to create a searchable index for the dummy data.

Creating Searchable Indexes using Pinecone API SDK

Pinecone is a vector database service designed for fast, scalable, and accurate intelligent search capabilities in applications. It allows you to store and retrieve vector representations of data efficiently, making it ideal for tasks like semantic search and recommendation systems.

What this means is that instead of relying solely on Anthropic AI LLM powering the Copilot to generate responses based on preexisting training knowledge, you can customize and contextualize the LLM so that your Copilot can address user queries and generate responses based on your app’s data. Ideally, this is why Pinecone becomes useful—it allows you to create vector databases for your data that are easily searchable with large language models.

Essentially, in this example, we are simply integrating Pinecone to create indexes for our knowledge base data. This way, the Copilot can first search through the data and generate more relevant, contextualized responses, along with accurately addressing follow-up questions based on the same knowledge base data.

Here’s a quick overview of what we’ll do:

Set up Pinecone.
Generating knowledge base content embeddings for the sample articles.
Indexing and querying the knowledge base data.

In the src/app/api/copilotkit/route.ts file, let’s start by making the following imports:

import { Pinecone } from '@pinecone-database/pinecone';
import {posts} from "@/app/lib/data/data";

Next, define your environment variables for the Pinecone and Anthropic API keys:

 const ANTHROPIC_API_KEY = process.env.NEXT_PUBLIC_ANTHROPIC_API_KEY;
 const PINECONE_API_KEY = process.env.NEXT_PUBLIC_PINECONE_API_KEY;

It’s a good practice to add a check to ensure these keys are provided Don’t worry—we’ll cover the steps for getting the Anthropic API key later on.

if (!ANTHROPIC_API_KEY || !PINECONE_API_KEY) {
  console.error('Missing required API keys. ');
  process.exit(1);
}

Now, initialize the Pinecone SDK, and set up the necessary configurations:

const pinecone = new Pinecone({ apiKey: PINECONE_API_KEY });
const model = 'multilingual-e5-large';
const indexName = 'knowledge-base-data';

We can now create the Pinecone index. An index is essentially a structured storage(numerical representations of data), that allows you to efficiently search and retrieve data based on vector similarity.

Ideally, for a production app, you would typically make API calls to retrieve your posts’ data dynamically. However, in this case, we will use the dummy data to simulate this process.

To create a vector database for our knowledge base data, we need to initialize a Pinecone index for the data.

Here’s the function to achieve this:

// Function to create the Pinecone index
const initializePinecone = async () => {
  const maxRetries = 3;
  const retryDelay = 2000;

  for (let i = 0; i < maxRetries; i++) {
    try {
      const indexList = await pinecone.listIndexes();
      if (!indexList.indexes?.some(index => index.name === indexName)) {
        await pinecone.createIndex({
          name: indexName,
          dimension: 1024,
          metric: 'cosine',
          spec: {
            serverless: {
              cloud: 'aws',
              region: 'us-east-1',
            },
          },
        });
        await new Promise(resolve => setTimeout(resolve, 5000));
      }
      return pinecone.index(indexName);
    } catch (error) {
      if (i === maxRetries - 1) throw error;
      console.warn(`Retrying Pinecone initialization... (${i + 1}/${maxRetries})`);
      await new Promise(resolve => setTimeout(resolve, retryDelay));
    }
  }
  return null; 
};

Once it’s set up, you can use it to store and retrieve your knowledge base data.

Next, we need to generate embeddings for your knowledge base. This step is crucial for enabling your application to efficiently store and search through large volumes of data using vector embeddings.

Embedding your knowledge base content is simply converting the raw data—typically text—into vectors that represent the semantic meaning of that data. Pinecone then stores these vectors in the index.

With the index in place, your application can perform operations like similarity search, allowing it to retrieve the most relevant data quickly based on the vector similarity between your queries and stored content.

To do that, add the following function:

// Initialize Pinecone and prepare the index
(async () => {
    try {
      const index = await initializePinecone();
      if (index) {
        const embeddings = await pinecone.inference.embed(
          model,
          posts.map(d => d.content),
          { inputType: 'passage', truncate: 'END' }
        );

        const records = posts.map((d, i) => ({
          id: d.id.toString(),
          values: embeddings[i]?.values ?? [],
          metadata: { text: d.content },
        }));  
        await index.namespace('knowledge-base-data-namespace').upsert(
          records.map(record => ({
            ...record,
            values: record.values || [],
          }))
        );
      }
    } catch (error) {
      console.error('Error initializing Pinecone:', error);
      process.exit(1);
    }
  })();

There are a few things we need to note:

Embeddings: These are vector representations of content, such as text or articles, that capture the semantic meaning of the data. In this case, embeddings are generated using Pinecone’s model, multilingual-e5-large, which processes the content and converts it into vectors. Note that you can also use other models, such as OpenAI, which provides an embedding API for this task.
Namespace: A namespace in Pinecone is a logical partitioning of your index. It allows you to organize data within the index and perform operations within specific segments of your data. In this case, the namespace is set to ‘knowledge-base-data-namespace’, which groups the knowledge base content together.
Records: These represent the data being inserted into Pinecone. Each record consists of an id, values (the embedding), and metadata (e.g., the text of the article). The values are what Pinecone uses to perform similarity searches, while the metadata provides additional context for each record.

Now, for setup this to work, you will need to get the Pinecone API key.

How to Get Your Pinecone API Key:

To get your Pinecone AI API Key, follow these steps:

Head over to the Pinecone Developer Console.

Select the API Keys tab, then click Create API Key. You can either use the default key or create a new one.

Specify the name of the key and click Create key.

Once you’ve completed these steps, return to your .env file, and paste the key:

NEXT_PUBLIC_PINECONE_API_KEY=your-api-key

Integrating the CopiloKit Node.js Endpoint

The final step is to add the CopilotKit Node.js endpoint to handle requests from the frontend.

Before proceeding, you’ll need to set up the Anthropic API to make requests to their service. To do that:

Create an Anthropic Account by visiting the Anthropic AI documentation to create an account and set up billing.

After logging into the Anthropic API console, generate your API key.

Once you have the API key, add it to your .env file in the root of your project:

Be sure to set up billing and quotas to enable your app to make API requests.

Remember, we added the CopilotKit API URL in the app’s client to allow it to forward requests to the CopilotKit backend for processing. To make this work, we need to define the CopilotKit API endpoint to manage and handle those requests. Let’s start by importing the following in the src/app/api/copilotkit/route.ts file:

import { CopilotRuntime, AnthropicAdapter, copilotRuntimeNextJSAppRouterEndpoint } from "@copilotkit/runtime";

import Anthropic from "@anthropic-ai/sdk";
import { NextRequest } from 'next/server'

The Copilot Runtime is the backend engine of CopilotKit, allowing apps to interact with LLMs. With it, you can define backend action for your copilots. And there are a ton of tasks you could specify, including executing internal database calls and managing different processes and workflows. However, for this specific example, we’ll define an action to query the Pinecone index for relevant articles based on the user query.

To do that, add the following code:

const runtime = new CopilotRuntime({
  actions: () => [
    {
      name: 'FetchKnowledgebaseArticles',
      description: 'Fetch relevant knowledge base articles based on a user query',
      parameters: [
        {
          name: 'query',
          type: 'string',
          description: 'The User query for the knowledge base index search to perform',
          required: true,
        },
      ],
      handler: async ({ query }: { query: string }) => {
        try {
          const queryEmbedding = await pinecone.inference.embed(
            model,
            [query],
            { inputType: 'query' }
          );
          const queryResponse = await pinecone
            .index(indexName)
            .namespace('knowledge-base-data-namespace')
            .query({
              topK: 3,
              vector: queryEmbedding[0]?.values || [],
              includeValues: false,
              includeMetadata: true,
            });
          return { articles: queryResponse?.matches || [] };
        } catch (error) {
          console.error('Error fetching knowledge base articles:', error);
          throw new Error('Failed to fetch knowledge base articles.');
        }
      },    },
  ],
});

Let’s break down this action handler. Ideally, this handle is the core engine for this entire integration. This action handler receives the query parameter passed from the Copilot client.

Using Pinecone’s query operation, the query is converted into a vector representation, which is then compared to the indexed vectors stored in Pinecone to identify the top three most relevant articles in the index. The result includes the vector values and metadata, which contain the actual matching data for the query.

Since most product knowledge bases have a ton of article posts, some even cover similar ideas, while others are totally different. It’s therefore practical to return multiple relevant pieces of data matching the query. (You can adjust the topK value to return the number of matching data objects based on your intended use case).

Finally, go ahead, and add the following code to define the CopilotKit endpoint as follows:

const anthropic = new Anthropic({ apiKey: ANTHROPIC_API_KEY });
const serviceAdapter = new AnthropicAdapter({ anthropic: anthropic as any });

export const POST = async (req: NextRequest) => {
  const { handleRequest } = copilotRuntimeNextJSAppRouterEndpoint({
    runtime,
    serviceAdapter,
    endpoint: '/api/copilotkit',
  });

    return handleRequest(req);


};

Make sure that the same URL you include in the CopilotKit API endpoint (/api/copilotkit) is specified in your frontend.

To test the entire app, navigate to your main project directory in the terminal and run the following command:

npm run dev

Then, head over to localhost:3000 in your browser and ask a question like “What features does CopilotKit offer?” in the Sidebar input field.

The result, is a fully functioning RAG Knowledge Base application using CopilotKit:

Users can continue asking additional questions; if you have a multitude of articles, instead of sifting through different pages, having the Copilot retrieve the information users need makes the process a whole lot easier.

For reference, or if you want to build on top of what we’ve covered in this article, you can clone this project’s source code from the GitHub repository.

Summary

In this guide, we have walked through the steps of building an Anthropic-powered Copilot using CopilotKit, Anthropic AI API, and Pinecone API for product knowledge bases.

While we’ve explored a couple of features, we have barely scratched the surface of CopilotKit's countless use cases, which range from building interactive AI chatbots to building agentic solutions. In essence, CopilotKit lets you add a ton of useful AI capabilities to your products in minutes.

If you’re looking to integrate AI-powered Copilots into your existing application, consider scheduling a demo, join the Discord Community of developers, and get started with the docs to try it out yourself!