DEV Community: Omer Farooq

The Anatomy of an AI Agent: Memory, Tools, Planning, and Execution Explained

Omer Farooq — Thu, 02 Apr 2026 21:01:27 +0000

Everyone's talking about AI agents. But most explanations jump straight to frameworks — LangChain, CrewAI, AutoGen — without explaining what an agent actually is under the hood.

Before you pick a framework, you need to understand the four building blocks every agent is made of: memory, tools, planning, and execution. Get these right in your head and every framework, every paper, every architecture diagram suddenly makes sense.

Let's break it down.

What Makes Something an "Agent"?

A regular LLM call is stateless. You send a prompt, you get a response, it's done. No memory of what came before. No ability to take action in the world. No loop.

An agent is different. At its simplest, an agent is an LLM in a loop — one that can observe its environment, decide what to do next, take an action, and then observe the result of that action before deciding again.

Observe → Think → Act → Observe → Think → Act → ...

That loop is what separates a chatbot from an agent. And the four components below are what make the loop work.

1. Memory — What the Agent Knows

Memory is how an agent maintains context — about the task, about past actions, about the world it's operating in. Without memory, every iteration of the loop starts from scratch.

There are four types of memory in agent systems:

In-context memory is the simplest kind — it's just the conversation history inside the LLM's context window. Everything the agent has seen and done so far, appended as a list of messages. Fast and easy, but limited by the context window size. For long-running tasks, it overflows.

External memory (vector stores) solves the overflow problem. Past interactions, documents, and knowledge are embedded and stored in a vector database like Supabase, Pinecone, or Chroma. When the agent needs information, it retrieves the most relevant chunks by semantic similarity rather than loading everything at once.

Episodic memory is a record of what the agent has done before — not the raw text, but structured summaries. "In run #12, the user asked about Dubai real estate and responded positively to AED pricing." This is how agents get better over time.

Semantic memory is domain knowledge — facts, rules, and context baked in via a knowledge base or system prompt. In a real estate agent, this is the RERA regulations, property types, and area guides.

In practice, most production agents use a combination: in-context memory for the current session, a vector store for long-term retrieval, and a structured knowledge base for domain facts.

2. Tools — What the Agent Can Do

An LLM on its own can only produce text. Tools are what connect that text to the real world — they let the agent read files, search the web, call APIs, write to databases, and send messages.

Every tool has the same basic structure: a name, a description (so the LLM knows when to use it), and a function that actually executes.

Here's a simple example using the Anthropic SDK's tool use format:

tools = [
    {
        "name": "search_properties",
        "description": "Search for available properties in a Dubai community. Use when the user asks about listings, availability, or pricing.",
        "input_schema": {
            "type": "object",
            "properties": {
                "community": {"type": "string", "description": "e.g. Downtown Dubai, JVC, Palm Jumeirah"},
                "bedrooms": {"type": "integer"},
                "max_budget_aed": {"type": "number"}
            },
            "required": ["community"]
        }
    }
]

The LLM reads the tool description and decides — based on the current context — whether to call it and with what arguments. This decision is called tool selection, and it's where the quality of your descriptions matters enormously. A vague description leads to wrong tool calls. A precise one leads to accurate, reliable behaviour.

Common tool categories in real-world agents:

Read tools — search, fetch, query (read-only, safe to call freely)
Write tools — create, update, delete (need guard rails)
Communication tools — send email, send WhatsApp, post to Slack
Compute tools — run code, calculate, transform data

A good rule of thumb: start with read-only tools and add write tools only once the agent's decision-making is reliable.

3. Planning — How the Agent Thinks

Planning is how an agent breaks a complex goal into a sequence of steps. Without planning, an agent can only handle single-shot tasks. With planning, it can handle multi-step workflows that take minutes or hours to complete.

There are two dominant planning patterns:

ReAct (Reason + Act) is the most common. The agent alternates between reasoning steps ("I need to find the user's budget before searching properties") and action steps (calling the search_properties tool). The reasoning is written out in natural language — often called a "scratchpad" or "chain of thought" — before each action.

Thought: The user wants a 2-bedroom in JVC under AED 1.2M. 
         I should search for listings first, then check payment plans.
Action: search_properties(community="JVC", bedrooms=2, max_budget_aed=1200000)
Observation: Found 8 listings. Cheapest is AED 980K at Bloom Heights.
Thought: Now I should get payment plan details for the top 3 listings.
Action: get_payment_plans(listing_ids=["BH-01", "BH-02", "BH-03"])
...

Plan-and-Execute is a two-stage approach. A planner LLM first generates the full sequence of steps as a structured plan. A separate executor LLM then works through each step. This is more reliable for complex tasks because the planning step can be reviewed or modified before execution begins.

Most agents you'll build day-to-day use ReAct. Plan-and-Execute is worth adding when tasks involve more than 5–6 sequential steps or when you need a human approval checkpoint mid-task.

4. Execution — The Loop That Holds It Together

Execution is the runtime — the code that drives the agent loop, manages state between steps, handles tool call results, decides when to stop, and surfaces output to the user.

A minimal agent loop in Python looks like this:

import anthropic

client = anthropic.Anthropic()

def run_agent(user_message: str, tools: list, system: str):
    messages = [{"role": "user", "content": user_message}]

    while True:
        response = client.messages.create(
            model="claude-sonnet-4-20250514",
            max_tokens=1024,
            system=system,
            tools=tools,
            messages=messages
        )

        # Agent has finished — return final text response
        if response.stop_reason == "end_turn":
            return response.content[0].text

        # Agent wants to use a tool
        if response.stop_reason == "tool_use":
            tool_use_block = next(b for b in response.content if b.type == "tool_use")

            # Execute the tool
            tool_result = execute_tool(tool_use_block.name, tool_use_block.input)

            # Append assistant response + tool result to message history
            messages.append({"role": "assistant", "content": response.content})
            messages.append({
                "role": "user",
                "content": [{
                    "type": "tool_result",
                    "tool_use_id": tool_use_block.id,
                    "content": str(tool_result)
                }]
            })
            # Loop continues — agent sees the result and decides next step

A few things worth noting in this loop:

stop_reason == "end_turn" means the agent decided it's done. This is your exit condition.
stop_reason == "tool_use" means the agent wants to call a tool. You execute it and append the result so the agent can continue.
The full message history is passed on every iteration. This is how the agent "remembers" what it has done so far in the current session.

The execution layer is also where you handle guardrails — maximum iteration limits (prevent infinite loops), cost controls (stop after N tool calls), and human-in-the-loop checkpoints (pause and ask before writing to a database).

Putting It All Together

Here's how the four components work as a system in a real scenario — a real estate lead qualification agent:

Component	What it's doing
Memory	Holds the lead's messages in-context; retrieves community pricing from a Supabase vector store
Tools	`search_properties`, `check_visa_eligibility`, `send_whatsapp`, `create_crm_lead`
Planning	ReAct loop: reasons about lead intent → searches listings → qualifies budget → decides to escalate or nurture
Execution	Python loop with a 10-iteration cap and a human escalation hook if confidence score drops below 0.6

None of these components is complicated on its own. The power comes from combining them — and understanding which one to improve when something goes wrong.

Agent giving wrong answers? Usually a memory problem — missing context or bad retrieval.
Agent calling the wrong tool? Usually a tools problem — vague descriptions.
Agent getting stuck in circles? Usually a planning problem — no clear stopping condition.
Agent crashing mid-task? Usually an execution problem — no error handling in the loop.

What's Next

Now that you understand the internals, you have a solid foundation for everything that comes next: multi-agent orchestration, RAG pipelines, streaming responses, and production deployments.

The framework you choose — LangGraph, CrewAI, or plain Python — is just scaffolding around these four components. Build one from scratch first. You'll understand every framework ten times faster once you've felt the loop run under your own hands.

I'm a Dubai-based AI engineer and automation consultant building agentic workflows and RAG pipelines for clients across UAE and Saudi Arabia. Follow me for more practical AI engineering content.

How I Built a Job Finder Agent with Claude AI, GitHub Actions, and Notion

Omer Farooq — Thu, 02 Apr 2026 20:40:06 +0000

I was spending 30+ minutes every morning trawling job boards for AI engineering and automation work. So I built an agent that does it for me — runs on a schedule, filters by relevance, scores each listing with Claude, and pushes everything into a clean Notion database. Here's exactly how I built it.

The Problem

As a freelance AI engineer targeting UAE and Saudi Arabia clients, I need to stay on top of new opportunities — but manually searching Upwork, LinkedIn, and niche job boards every day is exactly the kind of repetitive, pattern-matching task AI is built for.

I wanted a system that ran overnight, so my morning started with a curated inbox rather than a raw firehose.

Requirements:

Scrape listings from multiple sources
Filter out irrelevant ones automatically
Score the best matches using an LLM
Surface results somewhere I'd actually look — Notion

Architecture

The agent is a three-stage pipeline: fetch → score → store. GitHub Actions provides the scheduler and runtime so there's nothing to host or maintain.

GitHub Actions (cron: 0 6 * * *)
        ↓
Python scraper (Upwork RSS + Apify)
        ↓
Claude API (claude-sonnet-4)
        ↓
Notion Database (scored + tagged)

Step 1: Scraping Job Listings

I'm pulling from two sources: Upwork's RSS feed (yes, it still exists) and a lightweight scrape of relevant LinkedIn searches. The Upwork RSS endpoint is the easiest win — no auth, returns structured XML, and covers most of the categories I care about.

import feedparser
import requests
from dataclasses import dataclass
from typing import List

UPWORK_RSS = "https://www.upwork.com/ab/feed/jobs/rss?q=AI+automation+agent&sort=recency"

@dataclass
class JobListing:
    title: str
    description: str
    budget: str
    url: str
    posted_at: str

def fetch_upwork_listings() -> List[JobListing]:
    feed = feedparser.parse(UPWORK_RSS)
    listings = []

    for entry in feed.entries[:20]:  # latest 20
        listings.append(JobListing(
            title=entry.title,
            description=entry.summary[:800],
            budget=extract_budget(entry.summary),
            url=entry.link,
            posted_at=entry.published
        ))

    return listings

def extract_budget(text: str) -> str:
    # Budget appears in Upwork RSS as "Budget: $X" or "Hourly Range"
    import re
    match = re.search(r'(Budget|Hourly Range)[:\s]+([^\n<]+)', text)
    return match.group(2).strip() if match else "Not specified"

Note on scraping: Upwork's RSS is public and rate-limit friendly. For LinkedIn I use Apify's LinkedIn Jobs Scraper actor — it handles anti-bot measures and costs about $2/month at my usage volume. Totally worth it over fighting Playwright against their detection.

Step 2: Scoring with Claude API

This is where the agent gets its intelligence. I pass each listing to Claude with a structured prompt that asks it to score relevance (1–10), extract key details, and give a one-line reason for the score. The output is JSON so I can parse it directly into Notion fields.

import anthropic
import json

client = anthropic.Anthropic()

MY_PROFILE = """
  Skills: Claude API, n8n, Make.com, Python, FastAPI, Supabase RAG
  Experience: 16 years — fintech, maritime, fashion e-commerce, SaaS
  Target: AI automation, chatbots, agentic workflows
  Location: Dubai, UAE (remote preferred)
  Rate: $50–120/hr
"""

def score_listing(listing: JobListing) -> dict:
    prompt = f"""You are a job relevance scorer. Given a freelancer profile and a job listing, 
return a JSON object only — no preamble, no markdown fences.

Freelancer profile:
{MY_PROFILE}

Job listing:
Title: {listing.title}
Description: {listing.description}
Budget: {listing.budget}

Return this exact JSON shape:
{{
  "score": <1-10>,
  "match_reason": "<one sentence>",
  "required_skills": ["<skill1>", "<skill2>"],
  "budget_fit": "<low|good|high>",
  "action": "<apply|skip|maybe>"
}}"""

    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=300,
        messages=[{"role": "user", "content": prompt}]
    )

    return json.loads(response.content[0].text)

A few things I learned tuning this prompt:

Ask Claude to return "JSON only — no preamble, no markdown fences" — otherwise you'll get code blocks with backticks that break json.loads().
Include your actual rate range so Claude can judge budget_fit meaningfully.
Keep max_tokens low (300 here) — it forces concise output and cuts API cost significantly.

Step 3: Pushing to Notion

I created a Notion database with properties that map directly to Claude's output fields: Score (number), Action (select), Match Reason (text), Budget (text), and a URL column.

import os
from notion_client import Client

notion = Client(auth=os.environ["NOTION_TOKEN"])
DB_ID = os.environ["NOTION_DATABASE_ID"]

def push_to_notion(listing: JobListing, scored: dict):
    # Skip low-relevance listings
    if scored["score"] < 5:
        return

    notion.pages.create(
        parent={"database_id": DB_ID},
        properties={
            "Name": {"title": [{"text": {"content": listing.title}}]},
            "Score": {"number": scored["score"]},
            "Action": {"select": {"name": scored["action"].title()}},
            "Budget": {"rich_text": [{"text": {"content": listing.budget}}]},
            "Match Reason": {"rich_text": [{"text": {"content": scored["match_reason"]}}]},
            "URL": {"url": listing.url},
            "Posted": {"rich_text": [{"text": {"content": listing.posted_at}}]},
        }
    )

def run_agent():
    listings = fetch_upwork_listings()
    for listing in listings:
        scored = score_listing(listing)
        push_to_notion(listing, scored)
    print(f"Done. {len(listings)} listings processed.")

if __name__ == "__main__":
    run_agent()

Step 4: Scheduling with GitHub Actions

Store the script in a GitHub repo and use Actions to run it every morning at 6am UAE time (2am UTC). Secrets — the Anthropic API key, Notion token, and database ID — live in repo Actions secrets, never in code.

# .github/workflows/job-agent.yml

name: Job Finder Agent

on:
  schedule:
    - cron: '0 2 * * *'  # 6am UAE (UTC+4)
  workflow_dispatch:      # manual trigger for testing

jobs:
  run-agent:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: pip install anthropic notion-client feedparser requests

      - name: Run Job Agent
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          NOTION_TOKEN: ${{ secrets.NOTION_TOKEN }}
          NOTION_DATABASE_ID: ${{ secrets.NOTION_DATABASE_ID }}
        run: python job_agent.py

Tip: Always add workflow_dispatch alongside your cron trigger. It lets you run the agent manually from the GitHub UI without pushing a dummy commit — essential when testing prompt changes.

Results After Two Weeks

Metric	Number
Listings processed per week	~120
Listings pushed to Notion (score ≥ 5)	18–25
Claude API cost per run	~$0.04
Time saved per morning	~30 minutes

The Claude scoring accuracy was the biggest surprise. It correctly identifies listings that need skills I don't have (LangChain-heavy, blockchain, etc.) and filters them without me maintaining a keyword blocklist. Qualitative reasoning beats regex every time.

What I'd Do Differently

1. Add deduplication
The same listing can appear across two consecutive runs on Upwork. A quick check against existing URLs using notion.databases.query before creating each page fixes this.

2. Add memory via Supabase
Storing scored listings in a vector DB would let Claude compare new listings against historically successful ones — "this looks like the Branch.io project you won." That's a proper agentic feedback loop.

3. Surface top picks via WhatsApp
Notion is fine but a push notification is better. A simple Make.com scenario — trigger on new Notion page with score ≥ 8, send WhatsApp message — would make this feel truly agentic.

4. Migrate to Claude's tool_use
Defining a score_listing tool schema gives you validated, structured output with zero parsing risk. No more praying json.loads() doesn't throw. I'll migrate this in v2.

Final Thoughts

The whole agent is under 150 lines of Python. It runs for free on GitHub's hosted runners. The API cost is negligible. And it saves 30 minutes every morning.

The bigger lesson: you don't need LangChain, CrewAI, or a complex framework to build a useful agent. A loop, an LLM call, and a reliable output store is often enough. Start simple, then add complexity only when you hit a real limitation.

I'm a Dubai-based AI engineer and automation consultant. I build agentic workflows, RAG pipelines, and AI-powered tools for clients across UAE and Saudi Arabia. Follow me for more practical AI engineering content.

Building a RAG Pipeline with Claude API and Supabase

Omer Farooq — Mon, 30 Mar 2026 11:17:41 +0000

Building a RAG Pipeline with Claude API and Supabase

Tags: claude supabase rag ai

Retrieval-Augmented Generation (RAG) is one of those patterns that sounds academic until you actually build one — then you realize it's just smart plumbing. You store knowledge somewhere searchable, retrieve the relevant bits at query time, and feed them to an LLM as context. The LLM stops hallucinating because it's working from your data, not just its training weights.

In this article, I'll walk you through building a production-ready RAG pipeline using:

Claude API (Anthropic) — for generation and embeddings
Supabase — for vector storage via pgvector
Node.js — the glue

By the end, you'll have a pipeline that ingests documents, embeds them, stores them in Supabase, and answers questions grounded in that knowledge base.

Architecture Overview

[Documents] → [Chunker] → [Embedder] → [Supabase pgvector]
                                               ↓
[User Query] → [Embed Query] → [Similarity Search] → [Top-K Chunks]
                                                             ↓
                                               [Claude API + Context] → [Answer]

Two phases: ingestion and retrieval + generation.

Prerequisites

Node.js 18+
A Supabase project (free tier works)
An Anthropic API key

npm install @anthropic-ai/sdk @supabase/supabase-js dotenv

Step 1: Set Up Supabase for Vector Search

In your Supabase project, open the SQL editor and run:

-- Enable the pgvector extension
create extension if not exists vector;

-- Create the documents table
create table documents (
  id bigserial primary key,
  content text not null,
  metadata jsonb,
  embedding vector(1536)
);

-- Create an index for fast cosine similarity search
create index on documents
using ivfflat (embedding vector_cosine_ops)
with (lists = 100);

Note: The embedding dimension (1536) matches voyage-3 embeddings from Anthropic. Adjust if you use a different model.

Step 2: Initialize Clients

// lib/clients.js
import Anthropic from '@anthropic-ai/sdk';
import { createClient } from '@supabase/supabase-js';
import 'dotenv/config';

export const anthropic = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
});

export const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_SERVICE_ROLE_KEY
);

Step 3: Ingestion Pipeline

3a. Chunk your documents

Chunking strategy matters more than people expect. Too large and you dilute relevance; too small and you lose context. A 512-token chunk with 50-token overlap is a solid starting point.

// lib/chunker.js
export function chunkText(text, chunkSize = 512, overlap = 50) {
  const words = text.split(/\s+/);
  const chunks = [];

  for (let i = 0; i < words.length; i += chunkSize - overlap) {
    const chunk = words.slice(i, i + chunkSize).join(' ');
    if (chunk.trim()) chunks.push(chunk);
  }

  return chunks;
}

3b. Embed and store

// lib/ingest.js
import { anthropic, supabase } from './clients.js';
import { chunkText } from './chunker.js';

export async function ingestDocument(text, metadata = {}) {
  const chunks = chunkText(text);

  for (const chunk of chunks) {
    // Generate embedding via Anthropic Voyage
    const response = await anthropic.embeddings.create({
      model: 'voyage-3',
      input: chunk,
    });

    const embedding = response.data[0].embedding;

    // Store in Supabase
    const { error } = await supabase.from('documents').insert({
      content: chunk,
      metadata,
      embedding,
    });

    if (error) throw new Error(`Supabase insert failed: ${error.message}`);
  }

  console.log(`Ingested ${chunks.length} chunks.`);
}

Step 4: Retrieval

// lib/retrieve.js
import { anthropic, supabase } from './clients.js';

export async function retrieve(query, topK = 5) {
  // Embed the query
  const response = await anthropic.embeddings.create({
    model: 'voyage-3',
    input: query,
  });

  const queryEmbedding = response.data[0].embedding;

  // Call the Supabase match function
  const { data, error } = await supabase.rpc('match_documents', {
    query_embedding: queryEmbedding,
    match_count: topK,
  });

  if (error) throw new Error(`Retrieval failed: ${error.message}`);
  return data;
}

Add this SQL function to Supabase:

create or replace function match_documents(
  query_embedding vector(1536),
  match_count int default 5
)
returns table (
  id bigint,
  content text,
  metadata jsonb,
  similarity float
)
language sql stable
as $$
  select
    id,
    content,
    metadata,
    1 - (embedding <=> query_embedding) as similarity
  from documents
  order by embedding <=> query_embedding
  limit match_count;
$$;

Step 5: Generation with Claude

// lib/generate.js
import { anthropic } from './clients.js';
import { retrieve } from './retrieve.js';

export async function answer(userQuery) {
  const chunks = await retrieve(userQuery);

  const context = chunks
    .map((c, i) => `[${i + 1}] ${c.content}`)
    .join('\n\n');

  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 1024,
    system: `You are a helpful assistant. Answer the user's question using ONLY the context provided below. 
If the answer isn't in the context, say so — don't make things up.

Context:
${context}`,
    messages: [
      { role: 'user', content: userQuery },
    ],
  });

  return message.content[0].text;
}

Step 6: Wire It Together

// main.js
import { ingestDocument } from './lib/ingest.js';
import { answer } from './lib/generate.js';

// --- Ingest phase ---
const doc = `
Supabase is an open-source Firebase alternative built on PostgreSQL.
It provides a real-time database, authentication, edge functions, and storage.
The pgvector extension enables storing and querying high-dimensional vectors directly in Postgres.
`;

await ingestDocument(doc, { source: 'manual', topic: 'supabase' });

// --- Query phase ---
const response = await answer('What is Supabase and what does pgvector do?');
console.log(response);

What Good Output Looks Like

Supabase is an open-source alternative to Firebase, built on PostgreSQL. 
It offers a real-time database, authentication, edge functions, and storage.

The pgvector extension extends Postgres to support high-dimensional vectors, 
enabling you to store and query embeddings directly in the database — which 
is exactly what powers semantic search in RAG pipelines.

Grounded, accurate, no hallucination.

Production Considerations

Chunking

Experiment with chunk size — 256–1024 tokens is the practical range
Overlapping chunks help preserve sentence-boundary context
For structured docs (API references, tables), consider semantic chunking

Retrieval quality

Add a metadata filter to scope searches: { source: 'docs-v2' }
Consider re-ranking retrieved chunks with a cross-encoder before generation
Log retrieval scores — if similarity drops below ~0.75, you may need better chunking

Scaling

Use ivfflat for up to ~1M vectors; switch to hnsw for larger datasets
Batch embedding calls during ingestion to stay within rate limits
Cache embeddings for frequently queried terms

Cost

Voyage embeddings are significantly cheaper than running inference — embed aggressively
Claude Haiku works well for simple Q&A RAG; use Sonnet when reasoning depth matters

Wrapping Up

This is the core skeleton of a RAG pipeline that actually works. The real craft is in tuning it — better chunking strategies, hybrid search (BM25 + vector), metadata filtering, and smart context window management. But this foundation will take you from zero to a grounded, retrieval-backed Claude assistant in a single afternoon.

If you extend this with streaming responses, a chat history layer, or a file upload frontend — that's a natural follow-up article. Drop a comment if you'd like to see it.

Tags: #claude #supabase #rag #ai #nodejs

How to add chat into a VUE.JS app with TalkJS chat API

Omer Farooq — Mon, 20 Dec 2021 12:48:33 +0000

Adding a live chat feature to a web app is often complex. However, with recent developments in the web dev community and the inception of TalkJS, this formidable task has become a breeze. TalkJS is a turnkey solution for adding live chat to any web app. It provides an ever-customizable user interface, flexible notifications, and a powerful chat API out of the box. In this tutorial, we will look at how we can add a chat to an existing vue.js application in a matter of minutes.

Application Overview

A Great University runs our fictitious application. It allows their students to take live lectures, but it lacks the ability to chat with professors and amongst themselves in real-time. Currently, the web app consists of a landing page where the student’s log in with their university credentials (Name, Email and Password). Once they log in, they are taken to the live lecture. For simplicity’s sake, we have assumed that there’s only one live lecture, which in our case is just a YouTube video, and that all the students are already authenticated. The currentUser object we will use throughout the tutorial will contain data that we’ve received from the backend after the login and auth process. Our focus is on integrating a chat into an existing Vue app and not creating a whole app from scratch.

Adding TalkJS to our application

We begin by adding TalkJS to our application. This can be done in one of two ways.
If you use the Node Package Manager run the following command, it will save it as a dependency in the packages.json:

> npm install talkjs –save

If you use Yarn Package Manager, run the following command:

> yarn add talkjs

Now that you have TalkJS installed, you need to signup on their website and register your application. This is a very simple process, at the end of which you will receive your APPID. Keep hold of this, it’s very important, and we will use this later.

Creating the chatbox Vue Component

Every Vue component is housed in its own .vue file. In this case, here are the steps to be followed

We will create a component called MessageBox in MessageBox.vue.
Under the template, we create a div, as shown in the image below.
The div has a ref attribute set to “talkjs-container” we will use this to mount the actual chat box in this div later.
The tag is only used as a placeholder until the chatbox loads. We have added some styling, but that is left to the reader’s discretion.

<template>
  <div
    class="col-xs-4"
    id="talkjs-container"
    ref="talkjs-container"
    style="width: 90%; margin-top: 10px; height: 900px">
    <i>Loading chat...</i>
  </div>
</template>

Below is a template that is added through a script tag. This will contain all the setup and logic for the TalkJS chatbox. Here the first thing we need to do is import TalkJS. To do that, add the following at the start of the script section:

import Talk from “talkjs”;

Next, we export this component and name it MessageBox. This component will accept one prop of type object that contains the user’s information.
It has two variables that it needs to maintain, so we add conversation and chatbox to the data function.

<script>
import Talk from "talkjs";
export default {
  name: "MessageBox",
  data() {
    return {
      conversation: null,
      chatbox: null,
    };
  },
  props: {
    currentUser: {
      type: Object,
      required: true,
    },
  },

javascript
Our chatbox will render once our MessageBox component has mounted, and as such, all chatbox logic will have to run inside the mounted lifecycle function that Vue provides. The mounted function will be defined just below our props object, and it will look something like this.

Creating the Users

The Talk object we imported from TalkJS is promise-based. Hence we call the ready function and then add our logic as a call back to the .then() function. Here we create our use through Talk.User() function. It accepts a JSONobject with the ID, Name, Email, photo URL of our user, and a role we set to default. For the sake of demonstration, we have also added another dummy user Sebastian in the other variable. In your application, you would add your own users using their data from your database.

mounted() {
    Talk.ready.then(() => {
      // creating our user
      var me = new Talk.User({
        id: this.currentUser.id,
        name: this.currentUser.name,
        email: this.currentUser.email,
        photoUrl: "https://randomuser.me/api/portraits/men/83.jpg",
        role: "default",
      });

      // creating other users
      var other = new Talk.User({
        id: "654321",
        name: "Sebastian",
        email: "Sebastian@example.com",
        photoUrl: "https://randomuser.me/api/portraits/men/69.jpg",
        welcomeMessage: "Hey, how can I help?",
        role: "default",
      });

Establishing a TalkJS Session

There can’t be a chat if there’s no chat session, hence we establish a talk session and add it to our browser’s window’s instance.

 // establishing a new session if one doesn't already exists
      if (!window.talkSession) {
        window.talkSession = new Talk.Session({
          appId: "YOU_APP_ID",
          me: me,
        });
      }

The APPID you found on your dashboard will be used here to establish a connection if one doesn’t already exist. This connection will let us join chats and start conversations. You also specify the user trying to establish the connection by passing the current user as a theme object.

Creating a New or Joining an Existing Conversation

Next, we join or start an existing conversation. Each conversation on TalkJS has a unique id. These ids can be stored in your database and used when joining group conversations or a conversation with someone. For our demonstration we will hard code it to 1001, all the students joining this lecture will be added to the conversation with the ID 1001.

// connecting to a new or already existing conversation
      this.conversation = window.talkSession.getOrCreateConversation("1001");
      this.conversation.setAttributes({ subject: "Computational Theory 101" });

      // adding participants
      this.conversation.setParticipant(me);
      this.conversation.setParticipant(other);

The getOrCreateConversation() function will fetch the conversation if it already exists or create a new instance. Note that we are initializing the conversation variable we defined earlier, this is so we can access the conversation object later if necessary. Once the conversation has been initialized, we add its participants, and naturally, it is going to be the two users, me and others we created beforehand.

Creating an Inbox and Mounting it

Like a usual conversation, we will initializethe inbox variable we defined above using the createInbox function of our talkSession. We will pass our conversation as the focus of this inbox by setting selected to our conversation.

// creating the actual inbox/chatbox
      this.inbox = window.talkSession.createInbox({
        selected: this.conversation,
      });

Last but not the least, we will mount our inbox to the div we added a ref to in the template section. But before this, we need to ensure that the ref we are going to point to has been initialized. Which is why we will use Vue’s $nextTick() function. It will ensure that the following code runs only after the required div, and ref are rendered and are ready to be addressed. In order to mount the inbox, we just call the mount function on the inbox object and pass this ref of our div, which we set to “talkjs-container”.

The Result

With this we’ve successfully added a chat box to our application. This group chat supports up to 20 users in the basic plan and up to 40 in the growth plan; however, more refinements will drastically increase these limits, such as the rolling enterprise plan. The chatbox would look something like this. This is the default design, and you can change it endlessly from the TalkJS dashboard.

The below gif demonstrates the functional design of the Chatbox.

Create a direct messages feature like on Booking.com with TalkJS

Omer Farooq — Thu, 18 Nov 2021 11:04:28 +0000

Recently, we have managed to customize the TalkJS default UI theme to make chat lookalikes like Uber, WhatsApp, LinkedIn, and other chats. In the following article, we will make the Booking.com chat using the TalkJS Chat API. We will show you how to create the blue and white theme of the booking.com chat.

Things To Do

Open the Theme Editor and create a newgif theme named “booking chat.” Now integrate this theme with the application to preview the theme changes. The users can also get an idea by following the starter guide and having an easy preview with an HTML page without application integration.

Below is the default theme of the TalkJS Chat:

Following is a complete summary of the changes that the user has to perform for making a chat like Booking.com:

Change the header to dark blue and the header text to white.
Remove the avatar from the header.
Remove the search icon from the header.
Change the font weight and family of the header text to normal and Arial, respectively.
Remove the avatars from both sender and receiver chat.
Remove the timestamp and message status from the chat.
Change the chat background from the default white to any other color (as booking.com uses an image that Talk JS does not support yet).
Change the alignment, styles, and padding of the messages.
Change the client’s chat background to blue and the support agent’s chat to white.
Change the format of the chat to make it look like the booking.com speech bubbles.

Layout

Chat panel

The initial step is to open the layout section from the Theme Editor and click on the Chat panel dropdown. The next thing is to change the background color to white.

Note: We are going for white colour for this tutorial, and the users can choose to set any color of their choice. Following is an image for the demo:

Message field area

In the layout section, open the message field area section and change the background color to white. Doing this will change the area’s colour around the message input field to match the background color. Below is the image to demonstrate it:

ChatHeader

The first top-level component to alter is the ChatHeader. Open the stylesheet of the ChatHeader section from the left menu. Change the header CSS with the following CSS to set the background color of the header to dark blue. This change makes it look like the header of Booking.com chat:

.header {
 display: flex;
 align-items: center;
 height: 4.5rem;
 background-color: #002F7D;
 flex-shrink: 0;
}

The next thing is to change the title colour to white, set the alignment of the title, and change its font size to make it more similar to the booking.com chat. Replace the title CSS with the following CSS to make these changes:

.title {
 text-overflow: ellipsis;
 overflow: hidden;
 white-space: nowrap;
 color: white;
 font-size: 20px;
 padding-left: 30px;
}

Moreover, remove the and class from the header as these are unnecessary. To make the chat look like booking.com, remove the following lines from the ChatHeader stylesheet:
Line 35 (the search box).
Line 36 (else condition).
Line 38 to 40 (image on the left side).
Line 45, line 49.
Line 51 to 57.
Line 88 to 93 (image CSS).
Line 101 to 104 (search action).
Line 119 to 156 (search code).

Following is the modified header after going through all the changes:

UserMessage

The following top-level component to alter is the UserMessage. The user has to open the UserMessage stylesheet to make changes according to the booking.com chat layout. The user has to modify line 54 like the following to hide the avatars:

<t:set showAvatars="{{true}}"/> to  <t:set showAvatars="{{false}}"/>

Moreover, remove lines 58 to 62 in order to remove the avatar code from the file.

The next thing is to remove the timestamp and message delivery status/show status from the chat. Alter the MessageBody tag at line 73 to remove the following code from the file:

timestamp="{{ timestamp }}" floatTimestamp="auto" showStatus="{{ sender.isMe }}"

Another thing is to add the below CSS to in the file to add the triangle in order to customise the speech bubbles to make them look like booking.com chat bubbles:

Following is the CSS to alter the speech bubble by the sender:

.by-me .message:before {
 content: "";
 width: 0px;
 height: 0px;
 position: absolute;
 border-left: 10px solid #379EE0;
 border-right: 10px solid transparent;
 border-top: 10px solid transparent;
 border-bottom: 10px solid transparent;
 right: -20px;
 top: 40px;
}

Following is the CSS to alter the speech bubble by the receiver:

.by-other .message:before {
  content: "";
  width: 0px;
  height: 0px;
  position: absolute;
  border-right: 10px solid  #D3D3D3;
  border-left: 10px solid transparent;
  border-bottom: 10px solid transparent;
  border-top: 10px solid transparent;
  right: 189px;
  top: 30px;
}

Replace the .by-me .message CSS to change the background color, margins and borders to make it look like the booking.com chat:

.by-me .message {
   background-color: #379EE0;
   color: #fff;
   margin-right:20px;
   border-color:#379EE0;
}

Replace the .by-other .message CSS to alter the background color of the chat and the left margin:

.by-other .message {
   background-color: #D3D3D3;
    margin-left:20px;
}

The next thing to do is to replace the message CSS to align it with the speech bubble styling and the borders of the bubbles. Moreover, alter the font family, font-weight, and the font size of the chat to make it similar to the booking.com chat.

Note: Users can make the above changes in the Layout section by setting the font size and font family in the ChatPanel section.

.message {
  border-color: #E7ECEE;
 background-color: #E7ECEE;
 color: #111;
 padding: 20px;
 font-weight: 900;
 font-family: arial;
 position:relative;
  white-space: normal;
  border-radius: 0.5rem;
  border-width: 0px;
  border-style: solid;
  word-wrap: break-word;
  position: relative;
  display: inline-block;
  max-width: calc(100% - 15rem - 0.25rem - 0.25rem);
  font-size: 16px;
  font-weight:normal;
  padding: 0px;
}

By performing all these changes and replacements, the chat now looks like this:

The below gif demonstrates the functional design of the booking chat:

How to build a rider-driver chat like on Uber with TalkJS

Omer Farooq — Thu, 18 Nov 2021 07:28:15 +0000

Lately, we have used the Theme Editor of the TalkJS Chat API to develop some chat lookalikes like WhatsApp, Discord, UpWork, LinkedIn, and many more. This article implements a chat that looks like a chat between a rider and driver on the Uber application. We will implement the latest theme.

Things to do

Open the TalkJS Theme Editor and create a new theme named “rider-chat.” Integrate the theme with the application to view the theme changes.

Note: The users can follow the TalkJS starter guide to preview them on the HTML page without app integration.

The image shows the default theme of the TalkJS chat:

Following is a summary of the changes that the users need to make in order to achieve an Uber chat lookalike:

Change the header color to black and the header text to white
Change the chat’s font family to Arial (sans-serif)
Remove the avatar and search icon from the header
Remove the avatar from the right chat message (rider’s message)
Change the alignment of the rider messages
Remove the timestamp and message status from the chat
Add message read status in the rider’s chat
Change the rider’s chat background to blue
Change the format of the chat to make it look like the Uber speech bubbles.

Layout

Chat panel

The very first thing to do is to set the background color by using the Theme Editor. Open the layout section through the left menu and select the Chat panel dropdown. Set the background color using the following color code as an example:

Message Field Area

In the layout section, open the message field area section and change the background color to gray. Doing this will change the area’s colour around the message input field to match the background color. Below is the image to demonstrate it:

ChatHeader

The first section to alter is the ChatHeader. Open the stylesheet of the ChatHeader section from the left menu. Change the background color of the header to black by modifying its class, as in Uber.

Replace the header CCS with the following CSS to change the header background color:

.header {
 display: flex;
 align-items: center;
 height: 4.5rem;
 background-color: black;
 flex-shrink: 0;
}

The next thing is to change the title color in the title class to white. So the name of the user will appear white on the black background, like Uber. Moreover, replace the title’s CSS with the following code to change the color, font size, font family, margins, and padding:

.title {
 text-overflow: ellipsis;
 overflow: hidden;
 white-space: nowrap;
 color: white;
 font-family: arial;
 font-size: 20px;
 padding-left: 30px;
 margin-bottom: -60px;
}

Another thing to do here is remove the and class from the header. To make the chat look like Uber, remove line 35 (the search box), line 36 (else condition), line 38 to 40 (image on the left side), line 45, line 49, line 51 to 57, line 88 to 93 (image CSS), line 101 to 104 (search action), line 119 to 156 (search code).

Moreover, add the phone icon in the header by using the following code. Add the phone icon code after the div of the title class.

Note: The critical thing to notice here is that the TalkJS Chat API currently does not support the call feature. However, there is a way of using it by integrating with other call APIs like Daily. There is also an integration guide for the users to follow in such cases. Users can also add the SVG of icons to make the chat look more like Uber’s original chat.

<a class="clickable-phone-icn" href="#">
         <img class="phone-icon-img" src="https://icon-library.com/images/phone-icon-white-png/phone-icon-white-png-6.jpg" />
  </a>

Add the below CSS of phone icon for styling in header:

.phone-icon-img {
 max-width:7%;
 float:right;
 padding-top:30px;
}

Below is the illustration of the modified header:

UserMessage

Open the UserMessage file and make the changes according to the Uber rider and driver chat layout. Replace line number 60 with the following code to remove the rider’s avatar from the chat:

<Avatar t:if="{{ sender.id != previousSenderId and sender.isMe == false}}"

The next thing is to remove the timestamp and message delivered status or show status from the chat. Remove the following code from the MessageBody tag at line 73:

timestamp="{{ timestamp }}" floatTimestamp="auto" showStatus="{{ sender.isMe }}"

Another thing is to replace the message CSS with the following CSS in order to change the font style:

.message {
   white-space: normal;
   overflow: hidden;
   border-radius: 1.5rem;
   border-width: 1px;
   border-style: solid;
   word-wrap: break-word;
   position: relative;
   display: inline-block;
   max-width: calc(100% - 6rem - 0.25rem - 0.25rem);
   border-color: #E7ECEE;
   background-color: #E7ECEE;
   color: #111;
   font-family: arial;
}

Furthermore, replace the .by-me .message CSS with the following CSS to change the message background color, chat bubble style and make it look more like Uber speech bubble:

.by-me .message {
   border-color: #1E60E1;
   background-color: #286EF0;
   color: #fff;
   /* Space between avatar and the message */
   margin-right: 0.25rem;
   border-radius: 40px 40px 0px 40px;
   padding-left: 1rem;
}

Replace the CSS class .by-other .message with the given CSS to change the background color and the chat bubble style for the driver:

.by-other .message {
   /* Space between avatar and the message */
   margin-left: 0.25rem;
   border-radius: 40px 40px 40px 0px;
   background-color:#E1DFE3;
}

Remove the following CSS class to align the chat:

.by-me.previous-same {
   /* Avatar width (see Avatar component) */
      padding-right: 3rem; 
}

Moreover, add the following CSS code before the closing tag of the template, i.e., to display message read status. The users can customize to hide or display this div based on the message show status. However, for this article, the if condition displays the read status for all messages by the rider. Users can manipulate this if condition to get the results they want:

<div t:if="{{sender.isMe == true}}"
           class="read-msg">
           Read
   </div>

Add the following CSS of the message read status in the style section:

.read-msg {
   color: gray;
   margin-left: 368px;
}

By performing all these changes and replacements, the chat now looks like this:

It is very similar to the original Uber chat between the rider and the driver, thanks to the Theme Editor by TalkJS. The users can develop many such themes with the flexible, easy-to-use interface and minimal coding requirement environment of TalkJS Chat API.

The below GIF demonstrates the functional design of the rider-driver chat: