DEV Community: Natarajan Murugesan

Build a Practical AI Agent with Gemma 4, Real Tools, and a Local LLM

Natarajan Murugesan — Sat, 11 Apr 2026 19:35:38 +0000

Build a Practical AI Agent with Real Tools and a Local LLM

How to combine Tavily, OpenWeatherMap, and LangGraph into a clean local-first workflow

Most local LLM demos are either too simple to be useful or too complex to reuse.

I wanted something in the middle: a practical AI agent that can search the web, check live weather, and still keep the reasoning layer local. So I built a workflow using LangGraph, Tavily, OpenWeatherMap, and a local LLM running through Ollama.

The result is a clean local-first architecture where tools provide real-time facts and the model turns them into useful answers.

Why this matters

Local LLMs are great for privacy, experimentation, and cost control. But on their own, they do not know live weather or fresh web results.

That is where external tools become valuable.

In this setup:

Tavily provides current web search results
OpenWeatherMap provides live weather data
the local LLM handles reasoning and phrasing
LangGraph orchestrates the workflow

This combination creates something much more useful than a plain local chatbot.

Architecture at a Glance

Before looking at the code, here is the core workflow.

Rather than asking the model to do everything in one opaque step, I split the system into clear responsibilities:

a router node decides what kind of request it is
a Tavily node fetches fresh web results
an OpenWeatherMap node fetches live weather data
a local LLM node combines those results into the final answer

That makes the system easier to debug, easier to extend, and much easier to reason about.

The key design principle is simple: tools provide facts, the local LLM provides reasoning.

Why this architecture works

This pattern works because it separates responsibility cleanly.

The model is no longer expected to hallucinate current weather or pretend it knows the latest web information. Instead, tools provide live facts and the LLM focuses on synthesis, reasoning, and response generation.

That separation makes the system:

more reliable
easier to debug
easier to evolve over time
more practical for real applications

Example use cases

This kind of agent can answer questions like:

“What is LangGraph and why is it useful?”
“What is the weather in Amsterdam today?”
“Summarize today’s AI news and tell me whether I need a jacket this evening.”
“Give me a quick weather summary and travel advice for Rotterdam.”

That is where the stack becomes more interesting than a typical chatbot.

State schema

A simple state schema can look like this:

from typing_extensions import TypedDict

class AgentState(TypedDict):
    user_input: str
    intent: str
    city: str
    search_results: str
    weather_data: str
    response: str

This keeps the workflow explicit and makes it easier to inspect what each node is contributing.

Router node

The router decides whether the request needs:

web search
weather lookup
both

Here is a simple keyword-based version:

def router_node(state: AgentState):
    text = state["user_input"].lower()

    has_weather = any(
        word in text for word in ["weather", "temperature", "rain", "forecast", "jacket"]
    )
    has_search = any(
        word in text for word in ["what is", "latest", "news", "search", "explain", "why"]
    )

    if has_weather and has_search:
        return {"intent": "both"}
    elif has_weather:
        return {"intent": "weather"}
    else:
        return {"intent": "search"}

This is intentionally simple. A more advanced version could use an LLM-based classifier or structured intent routing.

Tavily search node

Tavily is a clean option for search in AI workflows because it returns structured results that are easy to pass into the next node.

from tavily import TavilyClient
import os

tavily = TavilyClient(api_key=os.environ["TAVILY_API_KEY"])

def tavily_search_node(state: AgentState):
    result = tavily.search(
        query=state["user_input"],
        topic="general",
        max_results=3,
    )

    lines = []
    for item in result.get("results", []):
        title = item.get("title", "")
        url = item.get("url", "")
        snippet = item.get("content", "")
        lines.append(f"Title: {title}\nURL: {url}\nSnippet: {snippet}")

    return {"search_results": "\n\n".join(lines)}

This node is responsible only for search. It does not try to answer the question yet.

OpenWeatherMap node

The OpenWeatherMap node handles live weather data. In this version, the city is resolved to coordinates first, and then current weather is fetched.

import os
import requests

OPENWEATHER_API_KEY = os.environ["OPENWEATHER_API_KEY"]

def get_coordinates(city: str):
    response = requests.get(
        "http://api.openweathermap.org/geo/1.0/direct",
        params={
            "q": city,
            "limit": 1,
            "appid": OPENWEATHER_API_KEY,
        },
        timeout=20,
    )
    response.raise_for_status()
    data = response.json()

    if not data:
        raise ValueError(f"No coordinates found for city: {city}")

    return data[0]["lat"], data[0]["lon"], data[0]["name"], data[0].get("country", "")

def openweather_node(state: AgentState):
    city = state["city"] or "Amsterdam,NL"
    lat, lon, name, country = get_coordinates(city)

    weather = requests.get(
        "https://api.openweathermap.org/data/2.5/weather",
        params={
            "lat": lat,
            "lon": lon,
            "appid": OPENWEATHER_API_KEY,
            "units": "metric",
        },
        timeout=20,
    ).json()

    summary = f'''
Location: {name}, {country}
Temperature: {weather["main"]["temp"]} °C
Feels like: {weather["main"]["feels_like"]} °C
Condition: {weather["weather"][0]["description"]}
Humidity: {weather["main"]["humidity"]}%
Wind speed: {weather["wind"]["speed"]} m/s
'''.strip()

    return {"weather_data": summary}

This node only retrieves and formats facts. It does not do interpretation.

Local LLM answer node

Once the tool results are available, the local LLM can turn them into a useful final answer.

from langchain_ollama import ChatOllama

llm = ChatOllama(
    model="gemma4:e4b",  # replace with your local gemma4 tag if available
    temperature=0,
)

def answer_node(state: AgentState):
    prompt = f'''
You are a helpful AI assistant.

Use the available tool results below to answer the user's request clearly.

User request:
{state["user_input"]}

Web search results:
{state["search_results"]}

Weather data:
{state["weather_data"]}
'''

    result = llm.invoke(prompt)
    return {"response": result.content}

This is the point where the local model adds value. It is not fetching data. It is turning tool outputs into a coherent response.

Build the LangGraph workflow

Here is how the graph can be wired together:

from langgraph.graph import StateGraph, START, END

graph = StateGraph(AgentState)

graph.add_node("router", router_node)
graph.add_node("tavily_search", tavily_search_node)
graph.add_node("openweather", openweather_node)
graph.add_node("answer", answer_node)

graph.add_edge(START, "router")

def route_after_router(state: AgentState):
    return state["intent"]

graph.add_conditional_edges(
    "router",
    route_after_router,
    {
        "search": "tavily_search",
        "weather": "openweather",
        "both": "tavily_search",
    },
)

graph.add_edge("tavily_search", "openweather")
graph.add_edge("openweather", "answer")
graph.add_edge("answer", END)

app = graph.compile()

This version keeps the orchestration explicit. You can easily expand it later with retries, memory, more tools, or better routing.

Run the agent

result = app.invoke({
    "user_input": "Summarize today's AI news and tell me if I need a jacket in Amsterdam",
    "intent": "",
    "city": "Amsterdam,NL",
    "search_results": "",
    "weather_data": "",
    "response": "",
})

print(result["response"])

Example output

For a weather-related prompt, the agent produced this response:

The weather in Amsterdam today is expected to be a clear sky.

Temperature: 9.22 °C

Feels like: 4.85 °C

Wind speed: 11.62 m/s

Humidity: 71%

Should you carry a jacket?

Yes. The wind makes it feel significantly colder than the actual temperature, so a jacket is definitely recommended.

This is exactly the kind of output I was aiming for: not just raw tool data, but a useful, human-readable answer grounded in live information.

At that point, the agent can combine fresh web information, live weather data, and local reasoning in one workflow.

Why I like this pattern

For me, this is where local LLMs become much more interesting.

Not as isolated chatbots.
Not as black-box “agents.”
But as reasoning layers connected to real tools.

This pattern gives me:

local-first reasoning
explicit orchestration
practical utility
easier debugging
a strong path for extension

That makes it useful both as a learning project and as a foundation for more advanced AI applications.

Final thoughts

This project reminded me that useful AI agents do not need to be huge or mysterious.

A small graph, a couple of well-chosen tools, and a local LLM are enough to build something genuinely practical.

LangGraph gives the structure. Tavily and OpenWeatherMap provide live facts. The local model turns those facts into useful answers.

That feels like a strong foundation for local-first AI systems.

Stop met tokens verspillen in OpenClaw

Natarajan Murugesan — Sun, 15 Mar 2026 10:58:02 +0000

OpenClaw Agents: verlaag LLM-kosten zonder kwaliteit op te offeren

De meeste teams proberen LLM-kosten te verlagen door prompts korter te maken, outputs in te korten of goedkopere modellen te gebruiken.

Dat helpt een beetje.

Maar in echte OpenClaw-omgevingen komt de grootste verspilling meestal ergens anders vandaan: inefficiënt runtime-gedrag.

Kapotte fallback-ketens, provider/auth-mismatches, verouderde sessiecontext en inconsistente agentconfiguraties kunnen ongemerkt zorgen voor meer retries, hoger tokengebruik, meer latency en ruis in logs.

De praktische les is simpel:

Optimaliseer eerst runtime-gedrag. Optimaliseer prompts daarna.

Waar de extra kosten meestal vandaan komen

In veel OpenClaw-deployments wordt vermijdbare uitgave veroorzaakt door:

gemengde model/provider-routing
fallbacks die wel geconfigureerd zijn, maar in de praktijk niet werken
langlevende sessies die oude geschiedenis meenemen
verschillende instellingen tussen vergelijkbare agents
terugkerende auth-, failover- of timeoutproblemen

Deze problemen creëren verborgen overhead nog vóórdat het model überhaupt een antwoord genereert.

Wat je als eerste moet oplossen

1. Gebruik één geldige geauthenticeerde route

Je primaire model moet overeenkomen met de credentials die de agent daadwerkelijk heeft.

Stel een geldige model.primary in
Verwijder fallbacks die afhankelijk zijn van ontbrekende credentials
Houd routing deterministisch

Alleen dit al kan mislukte pogingen en rumoerige uitvoerpaden verminderen.

2. Houd fallback-ontwerp minimaal

Fallback is bedoeld voor veerkracht, niet voor normale routing.

Een goede vuistregel:

houd de fallback-lijst op 0–2
neem alleen geteste, bruikbare entries op
vermijd cross-provider fallback tenzij die volledig ondersteund wordt

Lange fallback-ketens verhogen de kosten vaak meer dan dat ze risico verlagen.

3. Beperk de groei van context

Verouderde geschiedenis verhoogt stilletjes het aantal inputtokens.

Een praktisch patroon is:

contextPruning.mode = cache-ttl
contextPruning.ttl = 5m
compaction.mode = safeguard

Dit helpt prompt-bloat te voorkomen in chatintensieve omgevingen.

4. Reset inactieve sessies

Als sessies te lang actief blijven, blijven ze oude context meeslepen.

Een nuttige instelling is:

session.reset.idleMinutes = 15

Maak ook verouderde sessies leeg na grote configuratiewijzigingen, zodat oude metadata nieuwe runs niet beïnvloedt.

5. Lijn multi-agentbeleid op elkaar af

Als meerdere agents vergelijkbaar werk doen, houd ze dan op hetzelfde routing- en sessiebeleid, tenzij er een echte reden is om daarvan af te wijken.

Dat maakt gedrag voorspelbaarder over Slack, Telegram of andere kanalen heen.

Oud versus nieuw

Dimensie	Oud gedrag	Geoptimaliseerd gedrag	Impact
Primaire routing	Gemengde routes	Eén geauthenticeerde route	Duidelijk uitvoerpad
Fallback-afhandeling	Ongeldige fallback-pogingen	Kapotte fallback verwijderd	Minder retry-verspilling
Foutpatroon	Terugkerende auth/failover-ruis	Schonere logs	Makkelijkere triage
Contexttrend	Blijft groeien	TTL pruning + compaction	Minder prompt-bloat
Idle-gedrag	Verouderde sessies blijven bestaan	Idle reset na 15 min	Lager basis-tokengebruik
Agentconsistentie	Drift tussen agents	Gedeeld beleid	Voorspelbaardere operaties

Hoe je de wijziging valideert

Na het bijwerken van de configuratie:

voer openclaw status uit
bevestig de actieve modelroute
bekijk enkele minuten de logs
controleer op auth-fouten, failovers en timeouts
verifieer dat nieuwe sessies schoon starten

Een configuratie kan er correct uitzien en toch nog tokens verspillen tijdens runtime, dus validatie is belangrijk.

Wat je moet meten

Een eenvoudige KPI-set is al voldoende:

gemiddeld aantal inputtokens per beurt
aantal failover-fouten per dag
aantal auth-mismatches per dag
aantal timeouts per dag
cache read ratio
kosten per 100 gesprekken

Nuttige formules:

Token-efficiëntie

Nuttige antwoorden / Totaal aantal inputtokens
(Mislukte pogingen / Totaal aantal pogingen) * 100
((Huidige week - Vorige week) / Vorige week) * 100

Aanbevolen reviewritme:

Dagelijks: fouten en timeouts
Wekelijks: token- en kostentrends
Maandelijks: routingbeleid en modelreview

Belangrijkste conclusie

Kostenverlaging in OpenClaw is meestal niet eerst een promptprobleem.

Het is een probleem van uitvoeringsdiscipline.

De grootste besparingen komen meestal van:

model/provider/auth-afstemming
kort en geldig fallback-ontwerp
context pruning en compaction
sessie-resetbeleid
consistentie tussen agents
doorlopende meting

Als je die dingen eerst oplost, krijg je meestal tegelijk lagere kosten, meer stabiliteit en eenvoudiger beheer.

Stop Wasting Tokens in OpenClaw

Natarajan Murugesan — Sat, 14 Mar 2026 23:11:57 +0000

OpenClaw Agents: Reduce LLM Cost Without Sacrificing Quality

Most teams try to reduce LLM cost by shortening prompts, cutting output length, or switching to cheaper models.

That can help a little.

But in real OpenClaw setups, the biggest waste usually comes from somewhere else: runtime inefficiency.

Broken fallback chains, provider/auth mismatch, stale session context, and inconsistent agent configuration can quietly increase retries, token usage, latency, and log noise.

The practical lesson is simple:

Optimize runtime behavior first. Optimize prompts second.

Where the extra cost usually comes from

In many OpenClaw deployments, avoidable spend is caused by:

mixed model/provider routing
fallbacks that are configured but cannot actually run
long-lived sessions carrying stale history
different settings across similar agents
repeated auth, failover, or timeout issues

These problems create hidden overhead before the model even generates a response.

What to fix first

1. Use one valid authenticated lane

Your primary model should match the credentials the agent actually has.

Set a valid model.primary
Remove fallbacks that depend on missing credentials
Keep routing deterministic

This alone can reduce failed attempts and noisy execution paths.

2. Keep fallback design minimal

Fallback should be for resilience, not normal routing.

A good rule:

keep fallback list to 0–2
only include tested, usable entries
avoid cross-provider fallback unless fully supported

Long fallback chains often increase cost more than they reduce risk.

3. Control context growth

Stale history silently increases input tokens.

A practical pattern is:

contextPruning.mode = cache-ttl
contextPruning.ttl = 5m
compaction.mode = safeguard

This helps prevent prompt bloat in chat-heavy environments.

4. Reset idle sessions

If sessions stay alive too long, they keep dragging old context forward.

A useful setting is:

session.reset.idleMinutes = 15

Also clear stale sessions after major config changes so old metadata does not affect new runs.

5. Align multi-agent policy

If multiple agents do similar work, keep them on the same routing and session policy unless there is a real reason to differ.

That makes behavior more predictable across Slack, Telegram, or other channels.

Old vs New

Dimension	Old behavior	Optimized behavior	Impact
*Primary routing*	Mixed lanes	Single authenticated lane	Clear execution path
*Fallback handling*	Invalid fallback attempts	Broken fallback removed	Less retry waste
*Error pattern*	Recurring auth/failover noise	Cleaner logs	Easier triage
*Context trend*	Keeps growing	TTL pruning + compaction	Lower prompt bloat
*Idle behavior*	Stale sessions persist	Idle reset at 15 min	Lower baseline token use
*Agent consistency*	Drift between agents	Shared policy	Predictable operations

How to validate the change

After updating config:

run openclaw status
confirm the active model lane
watch logs for a few minutes
check for auth errors, failovers, and timeouts
verify new sessions start clean

A config can look correct and still waste tokens in runtime, so validation matters.

What to measure

A simple KPI set is enough:

avg input tokens per turn
failover errors per day
auth mismatch errors per day
timeouts per day
cache read ratio
cost per 100 conversations

Useful formulas:

Token efficiency

Useful responses / Total input tokens
(Failed attempts / Total attempts) * 100
((Current week - Previous week) / Previous week) * 100

Suggested review cadence:

Daily: errors and timeouts
Weekly: token and cost trend
Monthly: routing policy and model review

Final takeaway

OpenClaw cost reduction is usually not a prompt problem first.

It is an execution-discipline problem.

The biggest savings usually come from:

Model/provider/auth alignment
Short and valid fallback design
Context pruning and compaction
Session reset policy
Multi-agent consistency
Ongoing measurement

If you fix those first, you usually get lower cost, better stability, and easier operations at the same time.

Building Multi-Agent Slack Routing with OpenClaw

Natarajan Murugesan — Tue, 10 Mar 2026 08:46:34 +0000

As AI systems evolve, a single assistant is often not enough. Many workflows benefit from multiple specialized agents — each with its own personality, capabilities, and routing logic.

Recently I experimented with OpenClaw to build a multi-agent Slack integration, where different Slack accounts route conversations to different agents.

This mini post summarizes the key learnings.

Agent Setup in OpenClaw

The first step was creating two agents:

main – default assistant

nila – secondary agent with a different personality

Basic commands used during setup:

openclaw agents list
openclaw agents add nila

Once created, we configured bindings to map Slack accounts to specific agents.

openclaw agents bind --agent main --bind slack:default
openclaw agents bind --agent nila --bind slack:nila
openclaw agents bindings

Key behavior

Bindings in OpenClaw are exclusive per target.

This means:

slack:default → main agent
slack:nila → nila agent

A binding cannot be owned by multiple agents simultaneously.

This design prevents routing conflicts and keeps conversation ownership clear.

Multi-Agent Routing Concept

With the bindings configured, OpenClaw can route messages based on the Slack account interacting with the system.

Example routing flow:

Slack (default account)
        ↓
   main agent

Slack (nila account)
        ↓
   nila agent

This approach enables different agent personalities or capabilities within the same workspace.

Slack App Configuration

During setup we encountered a common Slack DM issue:

Sending messages to this app has been turned off.

In most cases, this is caused by Slack app configuration or installation state.

To enable bot DM interactions correctly, the following settings are required.
Required Slack App Settings

✔ App Home messages enabled
✔ Socket Mode enabled with a valid xapp- token
✔ Required bot scopes:

chat:write
im:read
im:history
im:write

After modifying scopes or permissions, always:

Reinstall the Slack app

Otherwise the new permissions will not take effect.

Debugging and Diagnostics

OpenClaw provides useful commands for troubleshooting routing and connectivity issues.

openclaw channels list
openclaw channels status --json
openclaw status
openclaw logs --follow

These commands help verify:

channel bindings
Slack connection status
agent routing
runtime logs

Important Behavior: Session Visibility

One subtle behavior we noticed involves cross-session communication.

If the policy
tools.sessions.visibility
restricts visibility, then:

agents may not be able to send messages across sessions

This is useful for enforcing isolation between agents.

Final Thoughts

OpenClaw’s routing model makes it surprisingly easy to build multi-agent Slack assistants.

With the right configuration, you can:

run multiple agent personalities
route conversations dynamically
isolate sessions for security
debug behavior through simple CLI tools

This architecture opens interesting possibilities for:

AI team assistants
domain-specific agents
developer copilots
automated workflows