Forem: Samuel Kyeremeh

Turning an Existing Express API into a Conversational Backend (Konsier Integration)

Samuel Kyeremeh — Fri, 10 Apr 2026 17:14:06 +0000

In Part 2, I broke down the architecture behind conversational systems:

Agents → Tools → Backend → Channels

Now let’s make it real.

In this post, I’ll walk through how I integrated this model into an existing Express API using Konsier.

No rewrite.
No new backend.

Just layering a conversational interface on top of what already exists.

Starting Point

I already had a simple Express + PostgreSQL backend.

It exposed endpoints like:

GET /menu
POST /orders
GET /orders/:id
PATCH /orders/:id

Typical setup:

Client → Express API → Database

The goal was:

Allow users to interact with this backend through chat (Telegram, WhatsApp, etc.)

without rewriting the API.

What Changes (and What Doesn’t)

The important thing to understand:

Your backend stays the same.

You’re not replacing your API.

You’re adding a new layer:

User (chat)
     ↓
Konsier
     ↓
Express API
     ↓
Database

Step 1 — Install Konsier

npm install konsier

If you're using Express:

npm install express

Step 2 — Define Your First Tool

Tools are how your agent interacts with your backend.

Start with something simple like fetching the menu.

```ts id="tool1"
import { Konsier } from "konsier";
import { z } from "zod";

const getMenu = Konsier.tool({
name: "get_menu",
description: "Returns all menu items",

input: z.object({
category: z.string().optional(),
}),

handler: async (input) => {
const items = await db.query("SELECT * FROM menu_items");
return { items: items.rows };
},
});




This is just a wrapper around your existing logic.

---

## Step 3 — Configure the Agent

Now define an agent that can use this tool.



```ts id="agent1"
const konsier = new Konsier({
  apiKey: process.env.KONSIER_API_KEY!,

  endpointUrl: "https://your-public-url.com/konsier",

  agents: {
    customer_support: {
      name: "Customer Support",
      description: "Helps users browse the menu",

      systemPrompt: "You help users find food and place orders.",

      tools: [getMenu],
    },
  },
});

The agent decides when to call get_menu.

Step 4 — Mount the Webhook

This is the connection point between Konsier and your backend.

```ts id="webhook1"
import express from "express";
import { serveKonsier } from "konsier/express";

const app = express();

serveKonsier(app, konsier);




This automatically:

* creates the webhook route
* validates requests
* routes messages to your agent

---

## Step 5 — Sync Your Configuration

Start your server and sync:



```ts id="sync1"
app.listen(3000, async () => {
  await konsier.sync();
  console.log("Server running");
});

This pushes your local agent + tools config to Konsier Cloud.

Step 6 — Connect a Channel

In the Konsier dashboard:

Create a project
Add your API key
Set your public /konsier endpoint
Link your agent
Connect a channel (Telegram, Slack, etc.)

Now send a message like:

“What food do you have?”

Your agent will automatically call get_menu.

End-to-End Flow

Here’s what happens when a user sends a message:

User → Telegram
        ↓
     Konsier
        ↓
   /konsier webhook
        ↓
     Agent
        ↓
     Tool (get_menu)
        ↓
     Database
        ↓
     Response → User

Key Takeaway

You didn’t rebuild your backend.

You didn’t duplicate logic.

You simply exposed your existing functionality as tools.

That’s the power of this approach.

What’s Next

So far we’ve only used a simple read operation (get_menu).

But real systems need more:

creating orders
updating orders
tracking status
handling edge cases

In Part 4, we’ll go deeper into tool design:

how to structure tools properly
how to validate inputs
how to avoid breaking your backend
and how to handle real business logic

If you're already running an Express backend, you're closer than you think to having a conversational interface.

In the next post, we’ll build real tools on top of it.

How AI Agents Actually Connect to Real Backends (Agents, Tools, Channels Explained)

Samuel Kyeremeh — Tue, 17 Mar 2026 16:16:01 +0000

In Part 1, I talked about why building conversational apps is still messy.

Now let’s get into the part that actually matters:

How do these systems really work under the hood?

If a user sends:

“I want 2 fried rice”

How does that message turn into a real backend action?

Not just a response — but something like:

creating an order
updating a database
returning a real result

To understand that, we need to look at the core building blocks behind modern conversational systems.

The Core Idea

At a high level, the architecture looks like this:

User (Telegram / Slack / WhatsApp)
            ↓
         Agent
            ↓
          Tool
            ↓
        Backend API
            ↓
         Database

Each piece has a very specific role.

1. Agent — The Brain

An agent is the AI layer that understands user messages and decides what to do.

It:

reads the user’s message
interprets intent
decides whether to respond directly or call a tool

You can think of it as the decision-maker.

But here’s the important part:

The agent should not contain your business logic.

It shouldn’t calculate totals, write database queries, or enforce rules.

That belongs in your backend.

2. Tool — The Bridge to Your Backend

A tool is just a function your agent can call.

For example:

get_menu
create_order
track_order

Instead of the agent guessing or hallucinating results, it calls a tool like:

create_order({
  items: [...]
})

That tool then runs real backend logic.

This is the most important concept:

Tools are the only safe way for agents to interact with real systems.

They:

validate input
execute real logic
return structured results

No guessing. No hallucination.

3. Backend — The Source of Truth

Your backend still does everything it normally does:

database queries
validation
business rules
calculations

Nothing changes here.

The agent doesn’t replace your backend.

It just sits on top of it.

4. Channels — Where Users Come From

Users don’t talk to your backend directly.

They come from platforms like:

Telegram
Slack
WhatsApp
Discord
Email
SMS

Each of these platforms has:

different APIs
different message formats
different authentication

This is where things usually get messy.

5. The Missing Piece: Routing

So how does everything connect?

That’s where the webhook layer comes in.

User → Channel → Webhook → Agent → Tool → Backend

When a user sends a message:

The channel sends it to your webhook
The agent processes it
The agent decides to call a tool
The tool runs backend logic
A response is sent back to the user

Where Konsier Fits In

Instead of building all of this yourself, Konsier provides a structured way to handle it.

It gives you:

a way to define agents
a way to define tools
a unified webhook layer
built-in support for multiple channels

So instead of wiring everything manually, you focus on:

defining what your system can do

and Konsier handles the rest.

Why This Model Works

This approach solves a major problem:

It separates AI reasoning from business logic.

The agent decides what to do
The backend decides how it’s done

That separation makes the system:

more reliable
easier to debug
easier to scale

A Simple Mental Model

If you remember nothing else, remember this:

Agent = decision maker
Tool = controlled execution
Backend = source of truth
Channel = entry point
Webhook = connection layer

What’s Next

Now that the architecture is clear, the next question is:

How do you actually plug this into an existing backend?

In Part 3, I’ll walk through how I integrated this model into an existing Express + PostgreSQL API using Konsier.

We’ll go from theory to actual code:

setting up the SDK
defining tools
mounting the webhook
syncing configuration

If you're building conversational systems, understanding this pattern will save you a lot of time.

In the next post, we’ll make it real.

Why Building AI Chat Apps Is Still Hard in 2026

Samuel Kyeremeh — Fri, 13 Mar 2026 17:58:02 +0000

Why Building AI Chat Apps Is Still Hard in 2026

A few months ago I tried building what sounded like a simple feature.

“Let users place orders through chat.”

Nothing fancy. Just a conversational interface that could talk to a backend and perform actions.

In my head, it felt like something that could take a weekend.

In reality, it quickly turned into a pile of moving parts.

LLM APIs.
Prompt tuning.
Conversation state.
API integrations.
Safety checks so the AI doesn’t hallucinate things like a 100% discount.

What looked like a small feature started feeling like I was assembling a mini distributed system.

And that’s when I realized something:

Conversational interfaces look simple, but building them is still messy.

The Illusion of a “Simple Chat Interface”

From the user’s perspective, chat feels incredibly simple.

They send a message.
The system replies.
Something gets done.

But behind that simple interaction, developers usually end up stitching together several different systems.

A typical conversational stack often includes things like:

LLM APIs
constantly switching models, providers, and pricing.
Prompt engineering
the strange craft of convincing a machine to behave consistently.
API integrations
teaching the AI how to actually perform useful actions.
Conversation state
making sure the bot remembers context between messages.
Business logic
preventing the AI from inventing features or hallucinating results.

Each of these pieces is manageable on its own.

But when you combine them, the system becomes surprisingly fragile.

The Real Problem: Too Many Responsibilities

When building conversational systems today, developers often end up responsible for far more than just backend logic.

You suddenly find yourself building:

a conversation orchestration layer
a tool execution system
integrations with messaging platforms
state management for conversations
guardrails around AI behavior

And then there’s distribution.

If you want your assistant to work across platforms like:

Telegram
Slack
WhatsApp
Discord
Email
SMS

you usually have to build separate integrations for each one.

Different webhooks.
Different payload formats.
Different authentication models.

The same logic ends up being repeated again and again.

What Developers Actually Want

Most developers don’t want to reinvent messaging infrastructure.

They just want something simpler:

Define what the AI can do
Connect it to real backend actions
Expose it across multiple channels

without rewriting everything for each platform.

In other words:

Focus on the business logic, not the plumbing.

A Different Approach

Recently, while experimenting with conversational interfaces, I came across an SDK called Konsier that tries to simplify this problem.

Instead of building separate bots or integrations for every messaging platform, the idea is to define your agents and capabilities once in code, while the SDK handles messaging channels and conversation infrastructure.

Your backend stays the source of truth, while the conversational layer becomes a thin interface on top.

The mental model was interesting enough that I decided to explore it further.

What This Series Will Cover

Over the next few posts, I’ll walk through:

the architecture behind conversational agents
how agents call backend tools safely
how messaging platforms connect to the system
how to integrate this into an existing Express backend
real bugs and production issues I ran into

The goal isn’t to promote a tool.

It’s to explore a practical pattern for building conversational backends.

Next in the Series

In Part 2, I’ll break down the core primitives behind this approach:

agents
tools
channels
webhooks
configuration sync

and how these pieces fit together to make conversational systems easier to build.

If you’re building chat interfaces in 2026, follow this series.

Next, we’ll dive into how agents call backend tools reliably without turning your backend into chaos.

Series

Part 1 — Why conversational apps are still hard
Part 2 — The architecture behind agents, tools, and channels
Part 3 — Integrating Konsier into an existing Express backend
Part 4 — Designing tools for real business logic
Part 5 — Production bugs and lessons learned