Mark Repka

Hello World

2026-02-13T00:00:00Z

Hey there! I'm Mark Repka, a Software Engineer based in Rochester, NY. I figured the best way to kick things off would be to introduce myself and share a bit about what I'm working on.

A Bit About Me

I graduated from the Rochester Institute of Technology in 2016 with a BS in Computer Science. During my time at RIT I was an active member and e-board member of RITlug, the RIT Linux Users Group, where I helped foster a community around Linux and open source software.

These days I work at Bitovi as a Software Engineer and JavaScript Consultant on the Systems Engineering team. Before Bitovi, I was a Software Engineer at Kodak Alaris working on the Kodak Moments web platform.

What I Work With

My primary focus is backend development with Node.js and TypeScript, but over the years I've picked up a broad toolkit. Here's a snapshot:

Languages: JavaScript, TypeScript, Bash, C#, Java, C/C++
Backend & APIs: Express, Restify, Koa, Hono, GraphQL
AI/LLM: OpenAI SDK, Anthropic SDK, Ollama, AWS Bedrock, LangChain, Model Context Protocol (MCP), Agent2Agent (A2A)
Infrastructure: Docker, Kubernetes, NGINX, Linux server administration
Cloud: Azure, AWS, DigitalOcean, Supabase
Databases: PostgreSQL, Redis, MongoDB, SQLite
Workflow: Temporalio
Frontend: React, Redux

I'm also a long-time Linux enthusiast. I've been running Linux on all of my personal machines since around 2009, generally Debian-based systems.

Projects

Outside of work, I like to tinker on side projects. A few highlights:

Hennos: A Telegram chat bot powered by large language models (OpenAI, Anthropic) that works in both one-on-one and group chat settings. This one has been a great playground for exploring AI tooling in a rapidly evolving ecosystem.
TeleIRC: A Go implementation of a Telegram-to-IRC bridge, originally built for the RITlug community. It's been starred over 150 times on GitHub and is used by groups around the world.
Project Lifeforce: A set of TypeScript REST APIs that power my various apps, websites, and services, providing server status, logging, and utilities.

You can find all of my open source work on GitHub.

What to Expect Here

I'm planning to use this blog to write about things I'm building, problems I've solved, and topics in software engineering that I find interesting, especially around backend development, AI tooling, and self-hosting. If any of that sounds interesting, stick around!

You can also find me on Bluesky and Telegram.

Building a Personal AI Assistant

2026-02-25T00:00:00Z

Back in February 2023, I started building a Telegram chatbot as a side project. The idea was simple: wire up the OpenAI API to a Telegram bot so I could ask it questions from my phone. Three years later, that throwaway experiment has evolved into Hennos, a full-featured, multi-platform AI assistant with 18+ tools, five LLM providers, and a persistent memory system. It's open source at repkam09/telegram-gpt-bot, and the live production instance is running at t.me/repka_gpt_bot.

This post walks through how it got here, the architecture decisions, the features that stuck, and the code that makes it all work.

How It Started

The very first commit on February 21, 2023 was a barebones Node.js script that took incoming Telegram messages, forwarded them to OpenAI's API, and sent the response back. It was maybe 100 lines of JavaScript.

By March I'd switched to the GPT-3.5 Turbo chat completions API, added basic group chat support so the bot could participate in Telegram group conversations, and started thinking about this as more than a toy. The single best early decision came in late April 2023: converting the entire codebase from JavaScript to TypeScript. At the time it seemed like unnecessary overhead for a side project, but given how much the project has grown since then, it was absolutely the right call.

Within the same week as the TypeScript conversion, I added voice message support. Users could send a voice memo to the bot, and it would be transcribed via OpenAI's Whisper API and processed as text. That handler is still surprisingly clean:

export async function handleVoiceMessage(
  user: HennosUser,
  path: string,
): Promise<HennosResponse> {
  const provider = user.getProvider();

  try {
    const transcription = await provider.transcription(user, path);
    if (transcription.__type === "string") {
      const response = await handlePrivateMessage(user, transcription.payload, {
        role: "system",
        content:
          "The user sent their message via a voice recording. " +
          "The voice recording has been transcribed into text " +
          "for your convenience.",
        type: "text",
      });
      return response;
    }

    return transcription;
  } catch (err: unknown) {
    const error = err as Error;
    Logger.error(
      user,
      `Error processing voice message: ${error.message}`,
      error,
    );
    return {
      __type: "error",
      payload: "Sorry, I was unable to process your voice message.",
    };
  }
}

The pattern of transcribe the input, inject a system hint about the input type, then pass it through the same text handler became a recurring design pattern. Voice, images, documents, and forwarded messages all funnel through a common pipeline, with small system hints giving the LLM context about what kind of input it's dealing with.

The Multi-Provider Architecture

One of the most important architectural decisions was abstracting away the LLM provider. Early on, Hennos was hardcoded to OpenAI. Then in late 2023 I added Ollama support so non-whitelisted users could still interact with the bot using local models without running up API costs. After that came Anthropic, Google Gemini, and most recently AWS Bedrock.

Every provider implements a common abstract base class:

export abstract class HennosBaseProvider {
  public client: unknown;
  public tokenLimit: number = 0;

  public abstract invoke(
    req: HennosConsumer,
    messages: HennosTextMessage[],
    schema?: boolean,
  ): Promise<HennosStringResponse>;

  public abstract completion(
    req: HennosConsumer,
    system: HennosTextMessage[],
    complete: HennosMessage[],
  ): Promise<HennosResponse>;

  public abstract moderation(
    req: HennosConsumer,
    input: string,
  ): Promise<boolean>;
  public abstract transcription(
    req: HennosConsumer,
    path: string,
  ): Promise<HennosResponse>;
  public abstract speech(
    req: HennosConsumer,
    input: string,
  ): Promise<HennosResponse>;
  public abstract details(): string;
}

This means all the handler code, tool-calling logic, and prompt construction don't care which model is actually running underneath. A user's provider selection is stored in the database and resolved at request time:

public getProvider(): HennosBaseProvider {
    if (this.whitelisted) {
        switch (this.provider) {
            case "openai":
                return HennosOpenAISingleton.instance();
            case "ollama":
                return HennosOllamaSingleton.instance();
            case "anthropic":
                return HennosAnthropicSingleton.instance();
            case "bedrock":
                return HennosBedrockSingleton.instance();
            default:
                Logger.warn(this, `Unknown provider ${this.provider}, defaulting to OpenAI`);
                return HennosOpenAISingleton.instance();
        }
    }
    return HennosOpenAISingleton.mini();
}

Non-whitelisted users are routed to a smaller "mini" model for cost control. Whitelisted users can switch between providers using a /settings command in Telegram. This was essential as the LLM landscape changed so rapidly that being able to swap from GPT-4 to Claude to Llama 3 without changing any application logic kept the project from getting locked into any single vendor.

The Permission System

Hennos has a tiered permission model that governs what each user can do. At its core, the system distinguishes between three levels: non-whitelisted users, whitelisted users, and admins.

Non-whitelisted users get a constrained experience. They can chat with the bot, but their messages are run through OpenAI's moderation endpoint first, they don't get persistent conversation history, and they only have access to a handful of basic tools. This was important for keeping the bot accessible without letting strangers rack up API costs or abuse the system:

async function handleLimitedUserPrivateMessage(
  user: HennosUser,
  text: string,
  context: boolean,
  hint?: HennosTextMessage,
): Promise<HennosResponse> {
  const prompt: HennosTextMessage[] = await hennosBasePrompt(user);
  const provider = user.getProvider();

  const flagged = await provider.moderation(user, text);
  if (flagged) {
    return {
      __type: "error",
      payload:
        "Sorry, I can't help with that. " +
        "Your message appears to violate the moderation rules.",
    };
  }

  const response = await provider.completion(user, prompt, [
    { content: text, role: "user", type: "text" },
  ]);

  return response;
}

Whitelisted users get the full experience: persistent chat history, tool calling, image/voice processing, and the ability to configure their preferred LLM provider. Admins get everything plus access to more powerful tools like Home Assistant smart home control.

The Tools System

Tool calling is where Hennos really started to feel like an assistant rather than a chatbot. The system currently has 18+ tools, organized into permission tiers so they can be selectively exposed based on the user's access level:

const PUBLIC_TOOLS = [
  SearXNGSearch,
  MetaFeedbackTool,
  MetaFeatureRequest,
  MetaBugReport,
];

const WHITELIST_TOOLS = [
  FetchWebpageContent,
  PerplexitySearch,
  OpenWeatherMapLookupTool,
  WolframAlpha,
  PythonSandbox,
  AcknowledgeWithoutResponse,
  ImageGenerationTool,
  CreateArtifact,
  SendImageFromURL,
  BraveSearch,
  MetaSetBotPreferredName,
  MetaSetUserPreferredName,
  MetaSetLLMProvider,
];

const EXPERIMENTAL_AVAILABLE_TOOLS = [
  JellyseerMediaRequest,
  JellyseerMediaSearch,
  AudiobookRequest,
  EbookRequest,
];

const ADMIN_TOOLS = [
  HomeAssistantEntitiesTool,
  HomeAssistantStatesTool,
  HennosRetrieveArtifact,
];

Every tool extends a BaseTool abstract class and implements three static methods: isEnabled() (checks if the required API keys/config exist), definition() (returns the OpenAI-compatible function definition), and callback() (executes the tool and returns a result). Here's the weather tool as a representative example:

export class OpenWeatherMapLookupTool extends BaseTool {
  public static isEnabled(): boolean {
    if (Config.OPEN_WEATHER_API) {
      return true;
    }
    return false;
  }

  public static definition(): Tool {
    return {
      type: "function",
      function: {
        name: "open_weather_map_lookup",
        description:
          "This tool utilizes the Open Weather Map API " +
          "to provide weather reports for specific locations. " +
          "To use this tool, you must supply the latitude and longitude " +
          "coordinates of the desired location.",
        parameters: {
          type: "object",
          properties: {
            mode: {
              type: "string",
              description:
                "Choose 'current' for present conditions " +
                "or 'forecast' for future predictions.",
            },
            lat: {
              type: "number",
              description: "Latitude of the location.",
            },
            lon: {
              type: "number",
              description: "Longitude of the location.",
            },
            units: {
              type: "string",
              description: "Available options are 'metric' or 'imperial'.",
            },
          },
          required: ["lat", "lon"],
        },
      },
    };
  }

  public static async callback(
    req: HennosConsumer,
    args: ToolCallFunctionArgs,
    metadata: ToolCallMetadata,
  ): Promise<ToolCallResponse> {
    const units = args.units ?? "metric";
    const mode = args.mode ?? "current";

    try {
      const url = `https://api.openweathermap.org/data/2.5/${
        mode === "forecast" ? "forecast" : "weather"
      }?lat=${args.lat}&lon=${args.lon}&units=${units}&appid=${Config.OPEN_WEATHER_API}`;

      const weather = await BaseTool.fetchJSONData(url);
      return [
        `Weather report for lat=${args.lat} lon=${args.lon}: ${JSON.stringify(weather)}`,
        metadata,
      ];
    } catch (err: unknown) {
      const error = err as Error;
      Logger.error(req, `open_weathermap_lookup_tool_callback error.`, error);
      return [`open_weather_map_lookup error`, metadata];
    }
  }
}

This pattern scales well. Adding a new tool means creating a single file, implementing the three methods, and adding it to the appropriate tier array. The tool results are passed back into the LLM as context, and the system supports recursive tool calls, the LLM can chain up to 8 tool invocations per request (configurable via HENNOS_TOOL_DEPTH) to reason through multi-step problems. For example, it might look up the user's location from the database, call the weather API, then format a natural language response.

The full range of tools covers quite a bit of ground:

Web search via Brave Search, SearXNG, and Perplexity AI
Knowledge lookups via Wolfram Alpha and web page fetching
Weather via OpenWeatherMap
Smart home via Home Assistant (admin-only)
Media requests via Jellyseer for movie/TV show requests to a Jellyfin server
Image generation via DALL-E, ComfyUI with Flux, and Gemini
Code execution via a Python sandbox (Terrarium)
Utility tools for user feedback, artifact creation, and bot customization

Conversation Memory

One of the key differences between a chatbot and an assistant is memory. Hennos stores all conversation history in SQLite via Prisma, so whitelisted users get persistent context across sessions. When I message it on Monday about a project, it still has that context on Wednesday.

The system prompt is constructed dynamically for each request, incorporating the user's preferences, location, whitelist status, and how long it's been since they last messaged:

export async function hennosBasePrompt(
  req: HennosConsumer,
): Promise<HennosTextMessage[]> {
  let botName = Config.HENNOS_BOT_NAME;
  let preferredName = req.displayName;

  if (req instanceof HennosUser) {
    const preferences = await req.getPreferences();
    if (preferences.botName) {
      botName = preferences.botName;
    }
    if (preferences.preferredName) {
      preferredName = preferences.preferredName;
    }
  }

  const prompt: HennosTextMessage[] = minimalBasePrompt(botName);

  prompt.push({
    role: "system",
    content:
      "In order to provide the best possible assistance you should " +
      "make use of various tool calls to gather additional information, " +
      "to verify information you have in your training data, and to make " +
      "sure you provide the most accurate and up-to-date information.",
    type: "text",
  });

  // ... user-specific context like name, location, permissions, last active time
  return prompt;
}

The prompt also includes temporal grounding, the current date and day of the week, so the model can answer time-sensitive questions accurately. The lastActive() method tracks how long it's been since the last message, giving the LLM context about whether this is a continuation of a recent conversation or a fresh interaction after hours or days.

The Telegram Integration

The Telegram service is by far the most developed integration. It handles text, voice, photos, documents, audio files, stickers, locations, contacts, forwarded messages, reply context, group chats, callback queries for inline settings, and even emoji reactions as typing indicators.

One neat feature is the message batching for private chats. If a user sends multiple messages in quick succession (common on mobile), the bot waits 2 seconds after the last message before processing them all as one combined input:

async function handleTelegramPrivateMessage(
  user: HennosUser,
  msg: MessageWithText,
) {
  // Reset the time between messages timer
  clearTimeout(PendingChatTimerMap.get(user.chatId));

  const current = PendingChatMap.get(user.chatId) || [];
  const cleaned = replaceTelegramBotName(msg.text, "Hennos", "ig");
  current.push(cleaned);
  PendingChatMap.set(user.chatId, current);

  // Set the timer to process the messages if we don't get any more within 2 seconds
  const timeout = setTimeout(async () => {
    PendingChatTimerMap.delete(user.chatId);
    const messages = PendingChatMap.get(user.chatId);
    PendingChatMap.delete(user.chatId);
    if (!messages) return;

    TelegramBotInstance.setTelegramIndicator(user, "typing");
    const response = await handlePrivateMessage(
      user,
      messages.length === 1 ? messages[0] : messages.join("\n"),
    );
    return handleHennosResponse(user, response, {});
  }, 2000);

  PendingChatTimerMap.set(user.chatId, timeout);
}

The bot also handles Markdown formatting gracefully. It attempts to send messages with Markdown parse mode first, and falls back to plain text if Telegram's Markdown parser rejects it. And long messages over 4000 characters get automatically chunked into multiple messages.

For group chats, the bot only responds when explicitly mentioned via @. But if TELEGRAM_GROUP_CONTEXT is enabled, it silently ingests all group messages into the conversation context, so when someone does @ it, the bot has full awareness of the recent conversation. Each message is tagged with the sender's display name so the LLM can track who said what in a multi-user conversation.

Beyond Telegram

While Telegram is the primary interface, Hennos also supports Discord with basic text and experimental voice channel integration, and Twitch chat. All platforms share the same core LLM logic, tool system, and permission model. There's even a CLI interface for local development and testing without any messaging platform involved.

The entrypoint of the application initializes whichever services are enabled via environment flags:

async function start() {
  Logger.info(undefined, "Starting Hennos bot...");

  await Database.init();

  const init = [];
  if (Config.TELEGRAM_ENABLED) {
    init.push(TelegramBotInstance.init());
  }
  if (Config.DISCORD_ENABLED) {
    init.push(DiscordBotInstance.init());
  }

  init.push(LifeforceBroadcast.init());
  await Promise.all(init);

  // In dev mode with no providers enabled, run the CLI
  const enabled = [Config.TELEGRAM_ENABLED, Config.DISCORD_ENABLED /* ... */];
  if (Config.HENNOS_DEVELOPMENT_MODE && !enabled.includes(true)) {
    await CommandLineInstance.run();
  }
}

Infrastructure and Deployment

Hennos runs in Docker with docker-compose, making deployment a single command. The stack includes SQLite via Prisma for all persistent data, with optional Qdrant for vector embeddings. A Caddy reverse proxy handles HTTPS termination for the Telegram webhook mode, which provides lower latency than the default polling approach.

Everything is configured through environment variables. Every API key, every feature toggle, every model selection. This makes it straightforward to run different configurations for development vs. production, or to spin up a version with only local Ollama models and no external API dependencies at all.

Lessons Learned

Building Hennos over the past three years has taught me a few things worth sharing:

Use the thing you build. Hennos is my daily driver. I use it for quick questions, weather checks, smart home control, media requests, and random curiosity throughout the day. That constant usage surfaces bugs and missing features faster than any test suite. Every tool I've added exists because I found myself reaching for it and it wasn't there yet.

TypeScript was the right call early on. Converting from JavaScript to TypeScript in the first two months felt like over-engineering a toy project. But refactoring a system with 18 tools, 5 LLM providers, and platform-specific handlers across Telegram, Discord, and Twitch would be genuinely painful without type safety. The early investment paid for itself many times over.

Provider abstraction was essential. The LLM landscape has moved so fast that being locked into a single provider would have been a constant source of friction. The abstract HennosBaseProvider class means I can adopt a new model the day it launches by implementing a single adapter, while all the tools, prompts, and handlers continue to work unchanged.

Tool calling is the line between chatbot and assistant. The moment Hennos could look up weather, search the web, and control my smart home, it stopped being a novelty and started being genuinely useful. The difference isn't intelligence, it's the ability to take actions in the real world.

Start simple, ship it, iterate. The first version was a few dozen lines of JavaScript. Three years later it's a multi-platform system with persistent memory, tool calling, and image generation. But every step along the way was small, incremental, and immediately usable. I never sat down to "build an AI assistant platform." I just kept making the thing I was already using a little bit better, one commit at a time.

What's Next

There's a lot more to talk about! I've been working on an agentic workflow system using Temporalio that fundamentally changes how Hennos handles complex multi-step tasks. That's a big enough topic for its own post, so stay tuned for a follow-up where I dig into the temporal-worker branch (which will hopefully be merged soon) and the architecture behind agentic AI assistant workflows.

Building a Personal AI Agent with Temporal Workflows

2026-02-27T00:00:00Z

After three years of iterative development on Hennos, my personal AI assistant project, it had become clear that the original architecture needed a major overhaul. The assistant had grown from a simple Telegram bot into a much larger multi-platform system supporting multiple LLM providers, several different chat clients, and a wide array of tools. But the original system that was designed around Telegram specifics was making it hard to seperate the core logic from the platform-specific interactions. There was a lot of duplicated logic, complex workarounds, and it was time for a fundamental rewrite.

This post documents the architectural transformation of Hennos from a simple handler-based system to a Temporal-powered workflow orchestration system. If you haven't read Part 1, check out Hennos Assistant V1 to understand the foundation we're building on.

Why Rewrite?

The original architecture worked well for simple interactions, but three problems became critical:

Complexity: Adding a new chat platform required significant changes to the core logic, making it hard to maintain and extend.
Database Limitations: The original database schema was not designed to handle anything other than Telegram-specific data, making it difficult to support multiple platforms and tools.
Observability: Debugging conversation flow meant digging through logs. There was no way to see the "state" of an active conversation or replay failures.

I needed a system that could handle durable, long-running conversations with built-in state management, retries, and visibility.

What is Temporal?

Temporal is a workflow orchestration platform. With Temporal, the core logic of your application is written as Workflows, durable functions that can run for days, months, or even years. These Workflows coordinate Activities, individual tasks such as calling an LLM, executing a tool, or interacting with external systems. As the Workflow executes, Temporal automatically persists the state to a database. If the process crashes, the Workflow can resume exactly where it left off. Similar, for Activities, if an Activity fails, Temporal can retry it based on configurable policies.

Even better, all of this can be observed and queried in real-time through Temporal's web UI.

For Hennos, this means:

Conversations are durable workflows that persist indefinitely
Each message is a signal that advances the conversation
LLM calls and tool executions are activities with automatic retries
The entire conversation history and state is queryable and observable in real-time

The New Architecture

The temporal-worker branch introduces several Workflow types, each serving a specific purpose:

1. Agent Workflow

The core of Hennos V2. Each conversation (whether from Telegram, Discord, Slack, or the web API) gets its own agent workflow. The Workflow implements a thought-action-observation loop:

This is simplified pseudo-code to illustrate the structure

export async function agentWorkflow(input: AgentWorkflowInput): Promise<void> {
  const context: string[] = input.continueAsNew
    ? input.continueAsNew.context
    : [];

  const pending: PendingMessage[] = input.continueAsNew
    ? input.continueAsNew.pending
    : [];

  let userRequestedExit = false;

  setHandler(agentWorkflowMessageSignal, (args: PendingMessage) => {
    pendingUserMessages.push(args);
  });

  setHandler(agentWorkflowExternalContextSignal, (args: string) => {
    context.push(args);
  });

  setHandler(agentWorkflowExitSignal, () => {
    userRequestedExit = true;
  });

  while (!userRequestedExit) {
    await condition(() => pendingUserMessages.length > 0 || userRequestedExit);

    if (userRequestedExit) break;

    // Process pending messages
    const userMessages = pendingUserMessages.splice(0);
    await activities.persistMessages(userMessages);

    // Think: Decide what to do
    const thought = await activities.think(context);

    if (thought.action === "respond") {
      await activities.sendResponse(thought.message);
    } else if (thought.action === "use_tool") {
      // Act: Execute the tool
      const result = await activities.executeTool(
        thought.tool,
        thought.parameters,
      );

      // Observe: Add result to history
      context.push(result);
    }

    // Re-evaluate after every action
  }
}

This pattern is based on the popular Reasoning and Acting (ReAct) Agent architecture. The workflow maintains conversation history, processes incoming signals, calls the LLM to decide what to do, executes tools if needed, and loops. If the process crashes, Temporal restarts the workflow from its last persisted state. If a tool execution fails, the Workflow can catch the error and respond appropriately. If a call to OpenAI or other API fails, Temporal can retry it automatically based on configurable policies.

2. Signal-Based Communication

Instead of synchronous request-response, the temporal-worker uses Signals to communicate with workflows. Here's how the Telegram client routes messages:

export async function handleTextMessage(msg: Message): Promise<void> {
  const chatId = msg.chat.id;
  const text = msg.text || "";

  // Get or create workflow for this conversation
  const workflowId = `telegram-${chatId}`;
  const handle = temporal.workflow.getHandle(workflowId);

  // Send signal to workflow
  await handle.signal("agentWorkflowMessageSignal", {
    platform: "telegram",
    chatId: chatId.toString(),
    userId: msg.from?.id.toString(),
    content: text,
    timestamp: new Date(),
  });
}

Signals are non-blocking. The Telegram bot sends the message signal and immediately returns. The workflow processes the signal when it's ready, potentially batching multiple signals together. This decoupling is critical for multi-platform support. In addition this makes it easy to add new platforms by simply sending signals to the same workflow.

3. Activities for LLM and Tools

Each individual task such as calling the LLM, executing a tool, or sending a response is implemented in an activity. Activities are functions that run outside the workflow, with configurable retry policies:

export const activities = {
  think: async (conversationHistory: Message[]): Promise<ThoughtResponse> => {
    // Get the list of available Tools
    const availableTools = getAvailableTools();

    // Call LLM to decide next action
    const prompt = buildThoughtPrompt(conversationHistory, availableTools);

    const response = await llm.chat({
      messages: prompt,
      tools: [
        {
          name: "perform_action",
          description: "Decide what action to take next",
          parameters: {
            reasoning: {
              type: "string",
              description: "Your thought process behind using this Tool",
            },
            tool_name: {
              type: "string",
              description: "The name of the Tool to execute",
            },
            tool_input: {
              type: "object",
              description: "The input parameters for the Tool",
            },
          },
        },
      ],
    });

    // Determine if the LLM wants to use a Tool
    // or returned a String to respond with.
    return parseThoughtResponse(response);
  },

  executeTool: async (toolName: string, input: any): Promise<string> => {
    // Execute tool with retries
    const tool = getToolByName(toolName);
    return await tool.execute(input);
  },

  persistMessages: async (
    messages: AgentWorkflowMessageSignal[],
  ): Promise<void> => {
    await db.workflowMessage.createMany({ data: messages });
  },
};

Activities have automatic retries with exponential backoff. If an OpenAI call times out, Temporal retries it. If a Tool execution fails, the Workflow can catch the error and respond appropriately.

4. ContinueAsNew for Long Conversations

As a Workflow executes, over time it will start to accumulate state. All of the conversation history, inputs and outputs of Activities, pending Signals, etc. For conversations that last months or years this will eventually become a problem. Thankfully, Temporal provides a solution here as well. Workflows can perform a continueAsNew, which starts a new instance of the Workflow with an initial state that we define.

export async function agentWorkflow(): Promise<void> {
  // ... signal handler code ...
  while (!shouldExit) {
    // ... ReAct Loop Logic ...

    const tokenCount = await tokens(context);
    const passedTokenLimit = tokenCount.tokenCount > tokenCount.tokenLimit;
    /**
     * ContinueAsNew if
     * - Temporal suggests it via workflowInfo().continueAsNewSuggested
     * - The conversation is nearing the LLM context length
     */
    if (workflowInfo().continueAsNewSuggested || passedTokenLimit) {
      const compactContext = await compact({ context });
      return continueAsNew<typeof agentWorkflow>({
        context: compactContext,
      });
    }
  }
}

The workflow restarts with a clean slate, with the existing context replaced with a summarized and compacted version. To the user, the conversation is seamless. To Temporal, it's a fresh workflow with reduced memory footprint.

Model Context Protocol (MCP) Integration

One of the biggest improvements in v2 is dynamic tool loading. The original Hennos had a bunch of hardcoded tools that were added simply to meet the use cases of the friends and family users as the project evolved. In v2, Tools are provided by MCP servers. These servers provide a standardized way to define tools and their capabilities. The original tools will continue to be available, but users will be able to configure their own MCP-defined tools and add them to Hennos themselves.

The Hennos API allows registering MCP servers per conversation:

app.post("/api/conversations/:id/mcp-servers", async (req, res) => {
  const { conversationId } = req.params;
  const { name, command, args, env } = req.body;

  // Register with conversation
  await db.modelContextProtocolServer.create({
    data: {
      name,
      conversationId,
      command,
      args: JSON.stringify(args),
      env: JSON.stringify(env),
    },
  });

  res.json({ success: true, serverId: server.id });
});

When the user next sends a message, the Workflow will load the configured MCP servers and make their tools available for use in the conversation. This means that new tools and capabilities can be added to Hennos without redeploying the application.

Multi-Platform Unification

One of the most powerful features of the temporal-worker rewrite is unified mode. In V1, each platform (Telegram, Discord) had isolated conversations. In V2, conversations can span platforms.

The database schema supports this via WorkflowSession and WorkflowSessionLink:

model WorkflowSession {
  id              String   @id @default(uuid())
  workflowId      String   @unique
  createdAt       DateTime @default(now())
  updatedAt       DateTime @updatedAt

  messages        WorkflowMessage[]
  links           WorkflowSessionLink[]
  mcpServers      ModelContextProtocolServer[]
}

model WorkflowSessionLink {
  id              String   @id @default(uuid())
  sessionId       String
  platform        String   // "telegram", "discord", "slack", "web"
  platformUserId  String
  platformChatId  String

  session         WorkflowSession @relation(fields: [sessionId], references: [id])

  @@unique([platform, platformChatId])
}

A single workflow can have multiple links. You could start a conversation on Telegram, continue it on Discord, and finish on the web interface. The key here is that all messages are routed to the same underlying Workflow, so the context is preserved across platforms.

Scheduled Workflows

Not all workflows respond to user messages. Hennos v2 introduces scheduled workflows for proactive tasks:

Email Digest Workflow

export async function emailDigestWorkflow(
  config: EmailDigestConfig,
): Promise<void> {
  while (true) {
    // Wait until next scheduled time (e.g., 8am daily)
    await sleep(config.scheduleInterval);

    // Fetch unread emails
    const emails = await activities.fetchEmails(config.emailAccount);

    // Summarize with LLM
    const summary = await activities.summarizeEmails(emails);

    // Update the chat history with the summary
    await activities.updateChatHistory(link.chatId, summary);
  }
}

This workflow runs indefinitely, waking up once per day to process emails. Temporal's durable timers ensure it never misses a run, even if the process restarts.

Bluesky Digest Workflow

Similar to Email, the Bluesky Workflow runs on a schedule fetching posts and summarizing them for delivery to configured platforms.

export async function blueskyWorkflow(
  config: BlueskyDigestConfig,
): Promise<void> {
  while (true) {
    await sleep(config.scheduleInterval);

    // Fetch Bluesky feed items
    const feedItems = await activities.fetchFeed(config);

    // Summarize with LLM
    const summary = await activities.summarizeFeedItems(feedItems);

    // Update the chat history with the summary
    await activities.updateChatHistory(config.chatId, summary);
  }
}

Now, when the user sends Hennos a message, it can have the additional context from their email inbox or Bluesky feed ready to go to provide a more informed response.

Observability and Debugging

Temporal comes with a built in Web UI that can be used to monitor workflows. The Web UI shows the complete Event History of our Workflow, all the inputs and outputs to Activities, incoming Signals, and more. It provides a great way to visualize what is happening in a Workflow and to debug issues.

This visibility is invaluable, especially for long-running conversations.

Code Quality Improvements

The rewrite forced better separation of concerns:

Client Layer (Telegram, Discord, Slack, API): Only handles I/O and signals. No business logic.
Workflow Layer: Coordination and state management. No LLM calls or tool execution directly.
Activity Layer: Pure functions for LLM calls, tool execution, database operations. Easy to test and reason about.
Singleton Services: Shared clients (OpenAI, Anthropic, Temporal) initialized once.

Activities can be tested in isolation. Workflows can be tested with mock activities. Clients are thin wrappers around Workflow Signals.

Performance and Reliability

Latency: Similar to V1 for simple messages, Temporal adds minimal overhead.
Reliability: No more lost conversations. Crashes are automatically recovered.
Scalability: Workflows are lightweight. A single Temporal cluster can handle thousands of concurrent conversations.
Concurrency: Multiple messages in rapid succession are batched in the workflow automatically, avoiding race conditions or the need for custom logic.

We can even see the workers that are associated with our Workflow in the Temporal Web UI:

Thanks to Temporals Workflow and Activity model, Hennos can also be horizontally scaled by adding more workers to the Temporal cluster.

What's Next?

In order to transition from the original Hennos v1 into Hennos v2 I actually implemented a second Temporal Workflow, re-implementing the entire behavior of Hennos v1 with its existing database and storage backends. Once this re-implementation is completed it should be possible to swap over to the new codebase. From there, the plan is to gradually migrate users to the new system. Likely another Temporal Workflow will be used to migrate data from the original database and storage over to the new Agent Workflow-managed history and WorkflowMessage database tables.

The largest remaining feature actually exists outside of the Hennos repository. The completion of the Hennos Web client implementation will provide a user-friendly interface for interacting with Hennos as well as linking together conversations from the legacy system.

Conclusion

Rewriting Hennos with Temporal transformed it from a chatbot into a durable, multi-platform agent orchestration platform. Conversations persist indefinitely. Tools are dynamically loaded. Workflows coordinate activities with retries and observability built-in.

If you're building an AI assistant that goes beyond simple request-response, consider workflow orchestration. The upfront complexity pays dividends in reliability, scalability, and developer experience.

I have also written more on this subject of Production Ready AI Agents for my consulting work at Bitovi. You can find that post here or many other AI-related blog posts here.

This is Part 2 of a series on Hennos. Read Part 1 to learn about the original architecture and evolution.

Bubbles and the Indie Web

2026-06-18T00:00:00Z

Bubbles

Yesterday I discovered bubbles.town, a website that aims to help the discoverability of small independent personal blogs.

From their /about page:

Somewhere out there, someone wrote a really good blog post today. You'll probably never find it. Google won't show it to you. Social media buried it under engagement bait. Bubbles tries to surface it. Community voting applied to thousands of personal, independent blogs, with identity and discussion routed through the Fediverse.

I read through many of the blog posts and found a lot of interesting content that I would not have discovered otherwise.

This led me down a bit of a rabbit hole exploring related indie and small web projects. It is very refreshing to see that this sort of movement exists. I'll have to spend some more time here and get my own website and blogs up and running!

I've spent a lot of my career building things on the web, and somewhere along the way the web stopped feeling like a place you could just wander. Things like StumbleUpon and the early days of Reddit with real user-surfaced content made it easy to find interesting things organically, but those experiences have become rarer over time.

The idea of owning your own corner of it, publishing on your own site first, and letting people actually find each other again, feels more important to me the bigger the social platforms get.

IndieWeb: We are a community of independent and personal websites based on the principles of: owning your domain and using it as your primary online identity, publishing on your own site first (optionally elsewhere), and owning your content.
Kagi Small Web: Kagi Small Web offers a fresh approach by promoting recently published content from the "small web." They gather new content, published within the last week, from a handpicked list of blogs and surface it via their search engine and APIs.

Morning Coffee

It is now the next day and I'm starting my morning at work by browsing bubbles.town again to see what new interesting blog posts have surfaced.

I have already learned something new about git from this post '.gitignore Isn’t the Only Way To Ignore Files in Git' by Nelson Figueroa. I also learned that web design doesn't always get along with flags from different nations, from this post 'PSA for web designers: flags have ratios!' by Ruben Schade.

I'm so inspired, in fact, that I felt the need to write something about it. This is a much better way to enjoy my morning coffee!