Forem: Rakesh Dhote

Your Cron Jobs Can't Think. These Can.

Rakesh Dhote — Sat, 09 May 2026 04:00:00 +0000

Every morning, the same ritual: open five tabs, skim headlines, paste into an LLM, wait for a summary, copy it to a file, forward it to Telegram. Manual. Repetitive. Skippable when you're busy — and that's exactly when you need it most.

I automated the entire thing — including the LLM call — in one TOML file. No Python. No Bash glue. No three separate cron entries. Zenii runs the whole pipeline on a schedule, passes outputs between steps, and fires off the Telegram message before I've poured my first coffee.

Here's exactly how it works.

The Workflow: Daily LLM Digest

Four steps. One schedule. The workflow fetches top news, summarises it with an LLM into a 5-bullet briefing, then fans out in parallel — saving the result to a local file and sending it to Telegram at the same time.

id = "daily-news-digest"
name = "Daily LLM Digest"
description = "Fetches top news, produces an LLM-summarized briefing, and sends to Telegram"
schema_version = 1
schedule = "15 11 * * *"

[[steps]]
name = "fetch_news"
type = "tool"
tool = "web_search"
args = { query = "top technology news today" }

[[steps]]
name = "summarize"
type = "llm"
prompt = "You are a news editor. Summarize the following search results into a concise 5-bullet briefing. Use markdown formatting.\n\n{{steps.fetch_news.output}}"
depends_on = ["fetch_news"]

[[steps]]
name = "save_briefing"
type = "tool"
tool = "file_write"
depends_on = ["summarize"]
args = { path = "/tmp/zenii/daily-briefing.md", content = "{{steps.summarize.output}}" }

[[steps]]
name = "notify_telegram"
type = "tool"
tool = "channel_send"
depends_on = ["summarize"]
args = { action = "send", channel = "telegram", message = "📰 *Daily News Digest*\n\n{{steps.summarize.output}}" }

[layout]
fetch_news = { x = 100.0, y = 0.0 }
summarize = { x = 400.0, y = 0.0 }
save_briefing = { x = 700.0, y = 0.0 }
notify_telegram = { x = 700.0, y = 150.0 }

How the Steps Connect

Zenii builds a directed acyclic graph (DAG) from the depends_on declarations. Cycles are rejected at save time. Steps with no dependencies run first; everything else waits for its upstream steps to complete.

In this workflow:

fetch_news runs immediately — no dependencies
summarize waits for fetch_news, then injects its output into the LLM prompt via {{steps.fetch_news.output}}
save_briefing and notify_telegram both depend on summarize — they execute in parallel, so the file write and the Telegram message happen at the same time

The [layout] section stores x/y coordinates for each node on the visual canvas. It has no effect on execution order — that's determined entirely by depends_on.

The template syntax {{steps.step_name.output}} works in any field — LLM prompts, tool args, condition expressions. You can also reference {{steps.step_name.success}} and {{steps.step_name.error}} for flow control.

For full DAG mechanics, retry policies, and failure handling, see Zenii Workflow Scheduling Documentation.

Create It in Plain English

You don't have to write the TOML by hand. Describe the workflow in plain English in Zenii's chat interface — it generates the full TOML, wires the depends_on graph, and sets the schedule for you.

Type what you want. Zenii generates the TOML, builds the graph, and registers the schedule.

The daily digest above was created from a single prompt:

"Create a daily news digest workflow that runs at 11:15 AM every day. It should search for top technology news, summarize the results, then save the briefing to /tmp/zenii/daily-briefing.md and send it to Telegram as 'Daily News Digest'."

The TOML in this post is exactly what Zenii produced. You can edit it afterward — or just describe a change and let the chat update it.

The Schedule Field

schedule = "15 11 * * *" registers the workflow with Zenii's built-in cron scheduler. Standard five-field cron syntax: minute hour day month weekday.

Expression	Meaning
`15 11 * * *`	Every day at 11:15 AM
`0 9 * * 1-5`	Weekdays at 9 AM
`/30 * * *`	Every 30 minutes
`0 8 1 * *`	First of every month at 8 AM

Zenii also supports interval syntax for simpler cases:

schedule = "every 300s"   # run every 5 minutes

And one-shot jobs that auto-delete after a successful run:

schedule = "0 10 * * *"
one_shot = true

The scheduler persists across daemon restarts via SQLite. Missed runs are tracked, and failures retry with exponential backoff: 30s → 60s → 5m → 15m → 1h.

The Node Palette

The type = "tool" step type connects to every node Zenii ships. The type = "llm" step type is its own first-class citizen — it takes a prompt field and calls your configured AI provider directly.

Here's the full palette:

Category	Node	What it does
AI	`llm_prompt`	Run a prompt against your configured AI provider
Search	`web_search`	Search the web and return ranked results
Search	`wiki_search`	Query your Zenii wiki knowledge base
System	`system_info`	Read CPU, memory, and OS details
System	`shell`	Execute a shell command and capture output
System	`process`	Start, stop, or inspect OS processes
Files	`file_read`	Read a file's contents
Files	`file_write`	Write content to a file
Files	`file_search`	Search files by name or pattern
Files	`file_list`	List directory contents
Files	`patch`	Apply a unified diff patch to a file
Memory	`memory_store`	Write a key-value fact to long-term memory
Memory	`memory_recall`	Retrieve from memory by semantic query
Memory	`memory_forget`	Delete a memory entry by key
Channels	`channel_send`	Send a message to Telegram, Slack, or Discord
Config	`config_read`	Read a value from Zenii's config
Config	`config_update`	Update a config value at runtime
Flow Control	`delay`	Pause for N seconds (useful for rate limiting)
Flow Control	`condition`	Branch on a boolean expression

The wiki_search node is worth calling out: it queries your local Zenii wiki — your own indexed documents, notes, and saved knowledge — and returns relevant passages. Combined with an llm step, your scheduled workflow can synthesize current web results against your private knowledge base. See Stop Rereading Your Documents. Let the AI Study Them Once. for how to build and populate your wiki.

More Workflow Ideas

A few quick sketches using different parts of the palette.

Weekly code health check — run tests on a schedule, only alert on failure:

id = "weekly-test-check"
schedule = "0 9 * * 1"

[[steps]]
name = "run_tests"
type = "tool"
tool = "shell"
args = { command = "cargo test 2>&1" }

[[steps]]
name = "check_result"
type = "tool"
tool = "condition"
depends_on = ["run_tests"]
args = { expression = "{{steps.run_tests.success}}", if_false = "alert" }

[[steps]]
name = "alert"
type = "tool"
tool = "channel_send"
depends_on = ["check_result"]
args = { channel = "telegram", message = "Tests failed:\n\n{{steps.run_tests.output}}" }

Memory-augmented research digest — search, summarize, and remember for next time:

id = "research-memory"
schedule = "0 18 * * *"

[[steps]]
name = "search"
type = "tool"
tool = "web_search"
args = { query = "Rust async runtime updates this week" }

[[steps]]
name = "summarize"
type = "llm"
prompt = "Summarize in 3 sentences:\n\n{{steps.search.output}}"
depends_on = ["search"]

[[steps]]
name = "remember"
type = "tool"
tool = "memory_store"
depends_on = ["summarize"]
args = { key = "rust-weekly-{{date}}", value = "{{steps.summarize.output}}" }

Config-driven topic digest — change the search topic from config without touching the workflow:

id = "topic-digest"
schedule = "30 8 * * *"

[[steps]]
name = "get_topic"
type = "tool"
tool = "config_read"
args = { key = "digest.topic" }

[[steps]]
name = "search"
type = "tool"
tool = "web_search"
depends_on = ["get_topic"]
args = { query = "{{steps.get_topic.output}} news today" }

[[steps]]
name = "summarize"
type = "llm"
prompt = "Summarize the key points:\n\n{{steps.search.output}}"
depends_on = ["search"]

[[steps]]
name = "send"
type = "tool"
tool = "channel_send"
depends_on = ["summarize"]
args = { channel = "telegram", message = "{{steps.summarize.output}}" }

Update the topic with zenii config set digest.topic "machine learning" and the next run picks it up.

Run It

Save the workflow file and register it:

zenii workflow create digest.toml

Test it immediately without waiting for the cron:

zenii workflow run daily-news-digest

Check the run history with per-step timing and output:

zenii workflow history daily-news-digest

List all scheduled workflows and their next fire times:

zenii schedule list

You can also trigger any workflow over HTTP from a CI pipeline, webhook, or MCP agent:

curl -X POST http://localhost:18981/workflows/daily-news-digest/run \
  -H "Authorization: Bearer $TOKEN"

One TOML file, one cron expression, one Zenii process. Your LLM pipeline runs while you sleep.

Full scheduling docs: https://docs.zenii.sprklai.com/scheduling

GitHub: https://github.com/sprklai/zenii — MIT licensed, open source.

If you build something with it, drop a link in the comments.

Stop Rereading Your Documents. Let the AI Study Them Once.

Rakesh Dhote — Fri, 08 May 2026 04:45:00 +0000

You read a research paper. Three weeks later, a question comes up. You can't remember the answer. You search your notes, find nothing useful, and paste the PDF into your AI assistant again. Same cost, same latency, and depending on the day, a slightly different answer.

This is the trap in naive RAG workflows: the system retrieves raw context, then re-synthesizes the answer on every query. For dynamic document stores, that's the right call. But for knowledge that doesn't change (research papers, architecture decisions, API conventions, meeting outcomes) you're paying the synthesis cost over and over for no reason.

Andrej Karpathy proposed a better pattern llm-wiki.md: compile the knowledge at ingest time. The LLM reads a document once, writes structured wiki pages, and future queries draw on pre-built knowledge. No regeneration. No inconsistency.

The catch: you have to build it yourself.

Zenii ships that pattern out of the box: ingest once, compile durable wiki pages, then query them from any tool through a local HTTP API.

Left: naive RAG pays synthesis cost on every query. Right: Zenii compiles at ingest — later answers read from stable pre-built pages.

What Zenii is

Zenii is a local-first AI assistant platform built in Rust. Its Desktop, CLI, TUI, and Daemon clients share one core library and talk to the same local HTTP + WebSocket gateway at 127.0.0.1:18981.

The wiki is the relevant part: a compiled knowledge layer every client and every external tool can query.

How the wiki works

When you ingest a document, the LLM runs a two-pass synthesis:

Entity pass: every named person, organization, tool, model, and dataset gets its own page. The rule is explicit: err on the side of more entity pages.
Concept synthesis: reusable ideas, comparisons, domain topics, and saved query answers are extracted and cross-linked.

Geometric Memory - The Secret to Implicit Reasoning and the Future of LLM Design.md — concepts, entities, and topics appearing on knowledge graph.

The output is 5–15 structured pages written under a typed taxonomy:

wiki/pages/
  concepts/     # techniques, patterns, abstract ideas
  entities/     # people, orgs, tools, models, datasets
  topics/       # domains that organize related pages
  comparisons/  # side-by-side analyses
  queries/      # saved answers to important questions

Every page uses a strict schema: YAML frontmatter and a markdown body with [[wiki-links]] for cross-references:

---
title: "Mixture of Experts"
type: concept
tags: [llm, architecture, efficiency]
related: ["sparse-activation", "switch-transformer"]
confidence: high
sources: [scaling-survey.pdf]
updated: 2026-05-05
---

## TLDR
Mixture of Experts routes each token to a subset of specialized subnetworks,
enabling models to scale parameters without proportionally scaling compute.
Underlies GPT-4, Mixtral, and other frontier models.

The LLM instructions that drive ingestion live in wiki/INGEST_PROMPT.md, a plain markdown file you can edit to tune how knowledge is compiled for your domain, without touching any code.

The structured output: typed taxonomy on the left, a rendered concept page on the right.

It's a local knowledge API

The wiki isn't a tab in a desktop app. It's an HTTP service. Any tool in your environment can call it.

# Ask from the CLI
zenii wiki query "What naming conventions do we follow for REST routes?"

# Ingest any document
zenii wiki ingest architecture-decision.pdf

# Call it from any language
curl -X POST http://localhost:18981/wiki/query \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"question": "What naming conventions do we follow for REST routes?"}'

The response comes back structured, not a re-synthesized paragraph, but a direct answer grounded in what the wiki knows:

{
  "answer": "Use plural nouns for collection routes and kebab-case for path segments.",
  "citations": ["api-conventions.md", "rest-routing.md"],
  "saved_page": null
}

import requests
from pathlib import Path

BASE = "http://localhost:18981"
HEADERS = {
    "Authorization": "Bearer <your-token>",
    "Content-Type": "application/json",
}

# --- Query the wiki ---
def query(question: str) -> dict:
    r = requests.post(f"{BASE}/wiki/query", headers=HEADERS, json={"question": question})
    r.raise_for_status()
    return r.json()

# --- Ingest a file from disk ---
def ingest_file(path: str) -> dict:
    with open(path, "rb") as f:
        r = requests.post(
            f"{BASE}/wiki/ingest",
            headers={"Authorization": HEADERS["Authorization"]},
            files={"file": (path, f)},
        )
    r.raise_for_status()
    return r.json()

# --- Ingest raw text (e.g. standup notes, changelogs) ---
def ingest_text(content: str, filename: str) -> dict:
    r = requests.post(
        f"{BASE}/wiki/ingest",
        headers=HEADERS,
        json={"content": content, "filename": filename},
    )
    r.raise_for_status()
    return r.json()

if __name__ == "__main__":
    # Ingest a document once — the LLM compiles it into wiki pages
    ingest_file("architecture-decision.md")

    # Query it any number of times — no re-synthesis, same answer every time
    result = query("What naming conventions do we follow for REST routes?")
    print(result["answer"])      # "Use plural nouns for collection routes…"
    print(result["answer"])      # "Use plural nouns for collection routes…"
    print(result["citations"])   # ["api-conventions.md", "rest-routing.md"]

    # Batch-ingest a directory of standup notes
    for note in Path("standups/").glob("*.md"):
        ingest_text(note.read_text(), note.name)
        print(f"Ingested {note.name}")

Every Zenii client (Desktop, CLI, TUI) reads from the same wiki. Via MCP, external AI agents like Claude Code or Cursor can call wiki routes as tools mid-conversation: query for conventions before suggesting a refactor, ingest a PR description before reviewing it.

Any automation platform that makes HTTP calls (n8n, Zapier, Make) can pipe documents straight into your wiki automatically.

Tool	What it gains
Cursor / Copilot	Query your conventions before suggesting code
Claude Code	Check architecture decisions before refactoring
n8n / Zapier	Auto-ingest meeting notes, changelogs, emails
Python scripts	Query the wiki programmatically in any workflow
Any LLM agent	Call `/wiki/query` as a tool — no RAG infra to build

One wiki. Every tool shares it. Cursor knows your conventions. Zapier ingests your meetings. Your agent recalls it all.

The desktop: knowledge as a graph

The Zenii desktop app renders your wiki as a visual knowledge graph. Concepts, entities, topics, and queries are nodes; the [[wiki-links]] between them are edges. Everything you've read, in one navigable view.

The rest of the system

Multi-format ingestion: PDFs, DOCX, PPTX, XLSX, images, and EPUBs are converted to markdown via the MarkItDown CLI before the LLM sees them. Originals stay untouched; re-ingestion always converts from the original binary, not a prior conversion.

Lint: zenii wiki lint finds broken wikilinks, orphan pages, missing metadata, and stale entries. --fix patches what it can automatically.

Memory sync: zenii wiki sync pushes page TLDRs into Zenii's hybrid memory (FTS5 + sqlite-vec). The agent recalls wiki knowledge across sessions without you having to ask.

Audit trail: content hashes, source-to-page mappings, and an append-only run log in .meta/. Re-ingestion is reproducible, and you can regenerate everything after editing your ingest prompt.

When not to use this

This is not a replacement for RAG over fast-changing data. If your corpus changes hourly (customer support tickets, live docs, recent news), retrieval still makes sense. The compiled wiki is for knowledge you want to stabilize: decisions, research, conventions, and long-lived project context.

Why compile instead of retrieve

Once ingested, answering a question reads only the relevant pages. No re-synthesis, no extra token cost, same answer every time. Knowledge improves incrementally: new sources add pages, lint keeps links clean, and regenerate lets you recompile everything as your prompt evolves.

Karpathy described the pattern. Zenii ships it as local infrastructure: one binary, one port, one knowledge base every tool in your environment can read from.

Zenii is in active development. Star it on GitHub or try the wiki API locally.

Add persistent AI memory to any script in 5 minutes (Python, Bash, Node — just curl)

Rakesh Dhote — Thu, 07 May 2026 02:26:00 +0000

Most AI tools forget everything the moment you close the tab.

Your scripts do the same. A deploy script cannot remember what happened last week. A project helper does not know your stack. A cron job starts from zero every morning.

Zenii changes that by giving your machine one shared AI memory. Store context from Python, recall it from Bash, ask from Node, or continue from the desktop app. Same memory. Same local backend. No framework, SDK, or hosted service required.

Here's a Python script with a memory that survives restarts, a Bash deploy script that remembers every deployment it ever ran, and a Node.js project assistant that knows your conventions. They're all 10-15 lines of code, and they share the same brain.

Setup (2 minutes)

Install Zenii as a single Rust binary, or download the app for your platform. Zenii is available to download on all platforms from the releases page.

# Linux / macOS
curl -fsSL https://raw.githubusercontent.com/sprklai/zenii/main/install.sh | bash

# Or download for your platform: https://github.com/sprklai/zenii/releases/latest

Start the daemon and add an AI provider key:

zenii-daemon &
# → Listening on 127.0.0.1:18981

# Add an OpenAI key (or Anthropic, Google, Ollama for offline)
curl -X POST localhost:18981/credentials \
  -H "Content-Type: application/json" \
  -d '{"key":"api_key:openai", "value":"sk-your-key-here"}'

Verify it's running:

curl localhost:18981/health
# → {"status":"ok"}

If the daemon isn't running, you'll get a connection refused error:

curl localhost:18981/health
# → curl: (7) Failed to connect to localhost port 18981: Connection refused

That's the only failure mode. Start the daemon and try again.

What if your machine just... knew things?

Before diving into language-specific examples, here's the core idea:

# Morning: store context from your deploy script
curl -X POST localhost:18981/memory \
  -H "Content-Type: application/json" \
  -d '{"key":"infra", "content":"Migrated staging to k8s, port 8443"}'

# Afternoon: ask from a completely different tool
curl -X POST localhost:18981/chat \
  -H "Content-Type: application/json" \
  -d '{"session_id":"ops", "prompt":"How do I connect to staging?"}'
# → "Staging is now on Kubernetes, port 8443..."

The memory persists across restarts, tools, and sessions. Store from Python, recall from Bash. Store from the desktop app, recall from Telegram. Everything shares the same brain.

Example 1: Python script with memory

import requests

BASE = "http://localhost:18981"

# Store something
requests.post(f"{BASE}/memory", json={
    "key": "project-config",
    "content": "The frontend uses React 19. The API is FastAPI on port 8000. Auth is JWT with RS256."
})

# Later (even days later), ask about it
resp = requests.post(f"{BASE}/chat", json={
    "session_id": "dev-helper",
    "prompt": "What framework does our frontend use and what auth scheme do we have?"
})

print(resp.json()["response"])
# → "Your frontend uses React 19, and authentication is handled via JWT with RS256 signing."

The memory is semantic — it uses FTS5 full-text search plus vector embeddings. So you don't need exact keyword matches. Ask "what auth do we use" and it'll find the answer even though you stored it as "Auth is JWT with RS256."

Example 2: Bash deploy script that learns

#!/bin/bash
# deploy.sh — a deploy script that remembers past deployments

# Store this deployment
curl -s -X POST localhost:18981/memory \
  -H "Content-Type: application/json" \
  -d "{\"key\":\"deploy-$(date +%F)\", \"content\":\"Deployed v2.3.1 to prod at $(date). Commit: $(git rev-parse --short HEAD). Duration: 4m22s\"}"

# Ask about deployment history
curl -s -X POST localhost:18981/chat \
  -H "Content-Type: application/json" \
  -d '{"session_id":"ops", "prompt":"Summarize recent deployments"}' \
  | jq -r '.response'

Every time you deploy, the script stores a memory. Over time, Zenii accumulates deployment history that it can summarize, compare, and reason about.

Example 3: Node.js project assistant

const BASE = 'http://localhost:18981';

async function storeContext(key, content) {
  await fetch(`${BASE}/memory`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ key, content })
  });
}

async function ask(question) {
  const res = await fetch(`${BASE}/chat`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ session_id: 'project', prompt: question })
  });
  return (await res.json()).response;
}

// Store your project context once
await storeContext('stack', 'Next.js 15, Prisma, PostgreSQL, deployed on Railway');
await storeContext('conventions', 'We use barrel exports, zod for validation, and server actions for mutations');

// Then ask questions from anywhere
console.log(await ask('How should I structure a new API endpoint based on our conventions?'));

Example 4: Scheduled morning briefing

curl -X POST localhost:18981/scheduler/jobs \
  -H "Content-Type: application/json" \
  -d '{
    "id": "morning-briefing",
    "name": "morning-briefing",
    "schedule": {"type": "cron", "expr": "0 9 * * 1-5"},
    "payload": {
      "type": "agent_turn",
      "prompt": "Search the web for top tech news today. Cross-reference with what I'\''ve been working on recently. Give me a 5-bullet briefing."
    }
  }'

Runs at 9 AM on weekdays. The agent searches the web (built-in tool), checks your stored memories for context, and generates a briefing. If you have Telegram or Discord channels configured, it can send the briefing there too.

The pattern

Notice what's happening: the language doesn't matter. Python, Bash, JavaScript, Go, Ruby — anything that can make HTTP requests can store memories and ask questions.

Zenii isn't a library you import. It's infrastructure you call. Like a database, but for AI.

The flow is always:

Store context via POST /memory
Ask questions via POST /chat (the agent uses stored memories automatically)
Schedule recurring tasks via POST /scheduler/jobs
Connect channels (Telegram, Slack, Discord) for multi-platform access

Advanced: giving your AI a personality

Want the agent to respond in a specific style? Zenii has a configurable identity system:

curl -X PUT localhost:18981/identity/SOUL \
  -H "Content-Type: application/json" \
  -d '{"content": "You are a senior DevOps engineer who gives concise, practical answers. You prefer command-line solutions over GUI workflows."}'

Now every response — from scripts, the CLI, Telegram, the desktop app — follows this persona. The personality is shared infrastructure, not per-tool configuration.

What you get vs. building it yourself

If you were to build a script with persistent AI memory from scratch, you'd need:

An AI SDK (openai, anthropic, etc.)
A database for memory (PostgreSQL, Redis, etc.)
Memory retrieval logic (embeddings, search, scoring)
Session management
Error handling and retry logic
A hosting solution if you want it always-on

With Zenii, you installed one binary and called curl. Everything else — memory, AI, tools, scheduling, error handling — is built into the daemon.

And if you later want to add Telegram, Slack, or Discord channels, it's the same pattern: configure credentials, register the channel, done. Same brain, new interface.

Full API reference

Everything here uses Zenii's REST API. Full docs: https://docs.zenii.sprklai.com

GitHub: https://github.com/sprklai/zenii | MIT licensed, open source.

If you build something with it, I'd genuinely love to see it. Drop a link in the comments or open a discussion on GitHub.

For the full architecture, see the Zenii architecture docs.