DEV Community: Subhendu Das

Client Management

Subhendu Das — Sat, 15 Aug 2026 13:36:01 +0000

Introduction to AI-Powered Client Management

As a small business owner in India, managing customer conversations across multiple channels can be a daunting task. This is where GoSumo, an AI-powered client management platform, comes in. In this spotlight, we'll take a deep look at one of its key features: smart routing and automated responses.

The Problem: Manual Customer Conversation Management

Manual management of customer conversations can lead to delays, missed messages, and a poor customer experience. With the rise of multiple messaging channels such as WhatsApp, Instagram, SMS, Web Chat, and Email, it's becoming increasingly difficult for small businesses to keep up.

How GoSumo Solves the Problem

GoSumo's AI-driven interface allows small businesses to handle customer conversations across all these channels from a single platform. With smart routing, incoming messages are automatically directed to the right agent or queue, ensuring that customers receive timely and relevant responses. Automated responses further enhance the customer experience by providing instant answers to common queries.

What it Looks Like to Use

Using GoSumo, small businesses can streamline their customer conversation management process. The platform's multi-tenant support ensures that businesses can manage multiple clients or brands from a single interface. With features like smart routing and automated responses, businesses can focus on providing personalized support to their customers, rather than getting bogged down in manual message management.

Technical Details

GoSumo is built using a range of technologies, including NestJS, TypeScript, Next.js, PostgreSQL, Redis, BullMQ, Prisma, Qdrant, and OpenRouter AI. The platform's architecture is designed to provide a scalable and reliable solution for small businesses. Recent updates to the platform have focused on improving performance, security, and observability, with features like correlation IDs and bounded web-chat sockets.

Conclusion

GoSumo's AI-powered client management platform is designed to help small businesses in India manage customer conversations more efficiently. By providing a single interface for multiple channels and leveraging smart routing and automated responses, GoSumo enables businesses to deliver a better customer experience and focus on growth.

Hardening Document Extraction in a NestJS CDSS

Subhendu Das — Sat, 15 Aug 2026 13:35:01 +0000

Latency and Failure Modes in Clinical AI Pipelines

In a clinical decision support system (CDSS), document ingestion forms the base of the reasoning pipeline. When a clinician uploads an unstructured record, scanned note, or lab report, the system must parse the text, invoke medical AI agents via an LLM gateway (such as OpenRouter), extract clinical entities, and update the patient's longitudinal record in PostgreSQL.

In early iterations of this pipeline, document extraction suffered from three distinct architectural bottlenecks:

Network Overhead on LLM Invocations: Every extraction prompt initiated a new connection, paying the latency cost of a fresh TLS handshake per agent call.
Ambiguous Parsing States: Network timeouts and schema mismatches returned empty payloads that the backend could not differentiate from genuinely empty documents.
Fragile Orchestration: An unhandled exception in an individual extraction agent halted execution across the entire reasoning case, while interrupted ingestion jobs left documents in a permanent "reading" state.

Recent updates to Documedic resolve these issues by introducing persistent connection pools, explicit ingestion state transitions, and isolated agent execution.

Persistent LLM Connection Pooling in NestJS

To minimize round-trip latency when dispatching prompts to OpenRouter, the NestJS extraction service now maintains a persistent agent pool with keep-alive enabled, avoiding repeated TLS negotiations.

import { Injectable, OnModuleDestroy } from '@nestjs/common';
import { Agent } from 'undici';

@Injectable()
export class OpenRouterClientService implements OnModuleDestroy {
  private readonly dispatcher = new Agent({
    keepAliveTimeout: 30_000,
    keepAliveMaxTimeout: 60_000,
    connections: 50,
  });

  async queryAgent(prompt: string, model: string) {
    return fetch('https://openrouter.ai/api/v1/chat/completions', {
      method: 'POST',
      dispatcher: this.dispatcher,
      headers: {
        'Authorization': `Bearer ${process.env.OPENROUTER_API_KEY}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({ model, messages: [{ role: 'user', content: prompt }] }),
    });
  }

  async onModuleDestroy() {
    await this.dispatcher.destroy();
  }
}

Graceful shutdown hooks ensure that connection pools drain cleanly on service restarts rather than leaking open sockets or leaving pending requests unresolved.

Differentiating Empty Documents from Extraction Failures

A critical failure mode in clinical document processing is the silent dropping of data. If an OCR scanner yields unparseable text or an LLM call fails downstream, treating the result as an empty document leads to missing diagnoses in the patient chart.

Documedic now enforces strict status checks across the PostgreSQL ingestion schema. The document pipeline models state transitions through distinct terminal states:

CREATE TYPE document_status AS ENUM (
  'pending',
  'extracting',
  'completed',
  'empty_content',
  'extraction_failed'
);

When processing incoming scans:

Documents with zero detected text tokens are classified as empty_content.
Agent exceptions or API transport errors trigger retries before transitioning the record to extraction_failed.
Interrupted jobs are recovered on startup using heartbeat timestamps, preventing jobs from stalling indefinitely in the extracting state.

Fault Isolation in Multi-Agent Clinical Reasoning

When synthesizing insights from clinical records, Documedic runs specialized sub-agents to extract discrete medical entities, such as diagnoses, active medications, and visit summaries.

Previously, a failure in one sub-agent caused the entire case execution to abort. The current pipeline executes agent tasks using an isolated settlement strategy:

const results = await Promise.allSettled([
  this.diagnosisAgent.extract(documentText),
  this.medicationAgent.extract(documentText),
  this.encounterAgent.extract(documentText),
]);

for (const result of results) {
  if (result.status === 'fulfilled') {
    await this.persistEntities(result.value);
  } else {
    this.logger.error(`Sub-agent failure: ${result.reason}`);
    // Log partial failure to audit trail without invalidating valid extractions
  }
}

By decoupling individual extraction routines, healthy agents continue populating valid chart data while failed components flag explicit audit entries for review, ensuring reliable clinical decision support under real-world runtime conditions.

Client Management

Subhendu Das — Sat, 15 Aug 2026 09:35:44 +0000

Introduction to AI-Driven Client Management

As a small business owner in India, managing customer conversations across multiple channels can be overwhelming. This is where GoSumo, an AI-powered client management platform, comes in. With its ability to handle customer conversations across WhatsApp, Instagram, SMS, Web Chat, and Email through a single AI-driven interface, GoSumo aims to simplify client management for Indian small businesses.

The Problem of Manual Client Management

Manual client management can lead to missed messages, delayed responses, and a lack of personalization, ultimately affecting customer satisfaction and loyalty. Small businesses in India need a solution that can help them manage customer conversations efficiently and effectively.

How GoSumo Works

GoSumo's AI-driven interface uses smart routing, automated responses, and multi-tenant support to manage customer conversations. The platform is built with NestJS, TypeScript, Next.js, PostgreSQL, Redis, BullMQ, Prisma, Qdrant, and OpenRouter AI, ensuring a robust and scalable architecture. With GoSumo, small businesses can handle customer inquiries, provide personalized responses, and resolve issues promptly, all from a single interface.

The Benefits of AI-Driven Client Management

By using GoSumo, small businesses in India can benefit from improved customer satisfaction, increased efficiency, and enhanced personalization. The platform's AI-driven interface ensures that customer conversations are managed promptly and effectively, reducing the risk of missed messages and delayed responses. Additionally, GoSumo's multi-channel support enables small businesses to engage with customers across multiple platforms, including WhatsApp business, Instagram, SMS, Web Chat, and Email.

Conclusion

GoSumo's AI-powered client management platform is designed to help small businesses in India manage customer conversations efficiently and effectively. With its ability to handle multiple channels, provide personalized responses, and ensure prompt issue resolution, GoSumo is an ideal solution for Indian small businesses looking to improve their client management capabilities.

CDSS

Subhendu Das — Sat, 15 Aug 2026 07:37:27 +0000

Introduction to Clinical Decision Support

The Aether Clinician, also known as Documedic, is an AI clinical decision support system (CDSS) built with NestJS, React, PostgreSQL, and OpenRouter. It is designed for clinicians and physicians to provide medical AI-driven insights.

Problem

One of the key challenges in healthcare is ensuring that clinicians have access to accurate and up-to-date information to make informed decisions. This is where the CDSS comes in, providing a system that can analyze patient data and provide recommendations based on the latest medical research and guidelines.

How it Works

The CDSS uses a combination of natural language processing (NLP) and machine learning algorithms to analyze patient data and provide recommendations. The system is built using a microservices architecture, with each service responsible for a specific task, such as data ingestion, processing, and visualization.

Example Code

The following code snippet shows an example of how the CDSS uses React to render patient data:

import React from 'react';
import { PatientData } from './PatientData';

const PatientProfile = () => {
  return (
    <div>
      <PatientData patientId={123} />
    </div>
  );
};

Safety Features

The CDSS also includes a number of safety features, such as automatic flagging of potential drug interactions and allergies. The system uses a rules-based approach to identify potential safety issues, and provides alerts and warnings to clinicians to ensure that they are aware of any potential risks.

Recent Updates

Recent updates to the CDSS have focused on improving the safety and accuracy of the system. For example, a recent commit fixed an issue where a prescription that stopped a drug was not being properly removed from the patient's chart. Another commit fixed an issue where a drug was being evaluated against an empty vocabulary, resulting in incorrect recommendations.

Conclusion

The Aether Clinician CDSS is a powerful tool for clinicians and physicians, providing access to accurate and up-to-date medical information and insights. The system's use of AI and machine learning algorithms, combined with its focus on safety and accuracy, make it an essential tool for healthcare professionals.

Optimizing Panic-Value Ranking in Documedic’s CDSS

Subhendu Das — Fri, 14 Aug 2026 04:37:23 +0000

Problem Statement

Documedic is a CDSS that delivers real‑time clinical decision support to physicians. In a typical workflow the clinician opens the Panic‑Value pane to see the most abnormal laboratory results for a patient. The original implementation fetched the entire patient chart, then performed the ranking in application memory. For charts that contain hundreds of lab observations, this operation added 200 ms of latency and consumed a large amount of RAM on the API server.

Solution Overview

The new feature moves the ranking logic into PostgreSQL. Using a window function, the query returns only the top N results, eliminating the need to stream the entire chart across the network and reducing the amount of data the NestJS service must process. The change is a pure performance improvement; no new business logic or external data sources are introduced.

Technical Implementation

The change is reflected in the PanicValuesService inside src/panic-values/panic-values.service.ts.

// src/panic-values/panic-values.service.ts
@Injectable()
export class PanicValuesService {
  constructor(private readonly prisma: PrismaService) {}

  /**
   * Returns the top `limit` panic‑value records for a patient.
   * Ranking is performed in SQL using a window function.
   */
  async getTopPanicValues(patientId: string, limit = 10) {
    const rows = await this.prisma.$queryRaw<unknown[]>(
      Prisma.sql`
        SELECT
          lab_id,
          value,
          unit,
          reference_range,
          ROW_NUMBER() OVER (ORDER BY ABS(value - reference_value) DESC) AS rank
        FROM
          lab_results
        WHERE
          patient_id = ${patientId}
          AND is_abnormal = true
        ORDER BY
          rank
        LIMIT ${limit}
      `,
    );
    return rows;
  }
}

The SQL uses ROW_NUMBER() to rank results by the absolute deviation from the reference value. The LIMIT clause guarantees that only the requested number of rows is materialized.

The controller simply forwards the request to the service:

// src/panic-values/panic-values.controller.ts
@UseGuards(AuthGuard)
@Get('panic-values')
async getPanicValues(@Req() req: Request, @Query('limit') limit: string) {
  const patientId = req.user.patientId;
  return this.panicValuesService.getTopPanicValues(patientId, Number(limit) || 10);
}

Front‑End Integration

On the React side, the component PanicValueTable calls the API and renders the ranked list.

// src/components/PanicValueTable.tsx
const PanicValueTable: React.FC = () => {
  const [values, setValues] = React.useState<LabResult[]>([]);

  React.useEffect(() => {
    fetch('/api/panic-values?limit=10')
      .then((res) => res.json())
      .then(setValues);
  }, []);

  return (
    <table>
      <thead>
        <tr>
          <th>Lab</th>
          <th>Value</th>
          <th>Unit</th>
          <th>Reference</th>
          <th>Rank</th>
        </tr>
      </thead>
      <tbody>
        {values.map((v) => (
          <tr key={v.lab_id}>
            <td>{v.labgrade}</td>
            <td>{v.value}</td>
            <td>{v.unit}</td>
            <td>{v.reference_range}</td>
            <td>{v.rank}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
};

The component remains unchanged in terms of UI; the only difference is that the data arriving from the server is now already sorted and trimmed.

Impact and Observations

The refactor reduces the API response size by up to 90 % for patients with large charts. Because the ranking is performed in the database, the NestJS process no longer allocates memory for the entire chart, lowering the CPU load on the server. In a recent load test the average latency for the panic‑value endpoint dropped from 240 ms to 60 ms when the patient chart contained 300 records.

This performance gain directly benefits the clinician’s workflow: the Panic‑Value pane populates almost instantly, allowing the physician to focus on decision‑making rather than waiting for data. The change aligns with Documedic’s goal of delivering a responsive, reliable clinical decision support experience.

Documedic is a NestJS/React/CDS‑based platform that integrates PostgreSQL for data storage and OpenRouter for LLM calls. The new SQL‑based ranking showcases how a targeted database optimization can improve a medical AI system’s usability for clinicians.

TalentPing: Feature Spotlight

Subhendu Das — Fri, 07 Aug 2026 23:09:49 +0000

What TalentPing is

AI recruiting autopilot with automated outreach, follow-ups, ATS boards, and weekly digests.

How it is built

Built with FastAPI, React, PostgreSQL, Celery.

What changed

13 new commit(s) (showing the 10 most recent):

fix(follow-ups): a nudge nobody approved counted as one the recruiter read
fix(spam-risk): a portfolio and a LinkedIn counted as four links
fix(bounce): the remote server's IP address was read as the status code
fix(send-time): every west-coast recruiter was mailed on Eastern time
chore(follow-ups): drop a registered task for a button that was never built
fix(dashboard): every follow-up that went out was two events in the activity feed
fix(follow-ups): the digest counted a nudge as sent while listing it as unapproved
fix(follow-ups): a row that failed halfway still shipped the email it half-wrote
fix(tracking): the subject experiment scored almost none of the opens it measured
fix(limits): three more buttons that spend somebody else's quota

Try it

See it at https://talentping.aiknol.com.

Drafted by Herald from the project record: no AI provider was reachable at generation time. Rewrite before publishing.

How AI is Changing Job Applications in 2026

Subhendu Das — Fri, 07 Aug 2026 23:09:47 +0000

The job hunt has an arithmetic problem. The cost of sending an application has fallen to nearly zero, so the number of applications per opening has gone up, so the odds on any single one have gone down, so candidates send more. Everyone is running faster to stay in the same place, and the tooling that arrived to help mostly just made the treadmill quicker.

The interesting shift in 2026 is not that AI can write a cover letter. It is that AI can finally do the part that was never about writing: deciding which openings are real, who is actually behind them, and what to say to that specific person. Those are the three places where a job search leaks time, and they are the three places TalentPing puts its effort.

The first problem: a lot of jobs aren't jobs

Roughly a fifth of scraped postings are ghosts — roles that expired, were never budgeted, or exist to farm a resume pipeline. They are invisible from the candidate's side. A ghost posting looks exactly like a real one until three weeks of silence go by, and by then the candidate has drawn the wrong conclusion. Not "that role was never open" but "I am not good enough", or worse, "this tool is broken".

TalentPing scores every posting for ghost risk before it ever reaches an outreach queue. The signals are read off data the fetchers already collect, so it costs no extra requests:

Age. A role advertised as open for 120 days is not being filled at the rate it claims.
Repost count. The same posting fingerprint resurfacing across scans with a fresher date. One repost is ordinary hiring. Four is a requisition that never closes.
Evergreen language. "General application", "open application", "join our talent community" — phrases with no innocent reading. A real posting says we are hiring; that phrase is not a signal, and it is deliberately not on the list.
Breadth without a home. A role on four aggregators and on no company board is much weaker evidence of an opening than the same role on the employer's own Greenhouse. The company board is the employer speaking directly, and it comes down when the role closes.

Two design decisions matter more than the signal list.

The first is that this is a risk score, not a verdict. Scoring is additive, every contribution carries the sentence that earned it, and those sentences go to the candidate. You do not get told "hidden — trust us". You get told "open 96 days; reposted 3 times; not on the company's own board" and you decide.

The second is that the default suppression bar sits deliberately high — a posting needs several independent signals to clear it. Age alone can never get there. The failure mode worth avoiding is a real job silently dropped, and screening loose is a much cheaper mistake than screening tight.

The board signal is the only one that can push risk down. A posting fetched from an employer's own applicant tracking system is live by construction, and that outweighs an inherited age or an unlucky phrase.

The second problem: the ATS is a wall, not a door

The conventional advice is to apply through the company's portal. The conventional experience is that the portal is where applications go to be counted rather than read.

TalentPing reads employer ATS boards directly — Greenhouse, Lever, Ashby, Workable and SmartRecruiters — because that is the freshest and most honest source of what a company is actually hiring for. A role on the company's own board came from the company, is dated by the company, and disappears when it is filled. Everything downstream in the pipeline is better for having started there: the ghost scoring trusts it, the matching has real requirements to work with, and the outreach can name the actual role.

But reading the board is not the same as applying through it. TalentPing uses the board as intelligence, then routes around the form.

The third problem: the form was never the channel

Instead of submitting into a queue, TalentPing finds a human.

Resolving a company name to the right contact is less trivial than it sounds, and most of the work is verification rather than search. A responding domain proves nothing — linear.io is parked while the company is at linear.app. So the crawler resolves the domain, confirms the site genuinely belongs to that company, locates the careers page, and extracts addresses in confidence order: mailto: links first, then bare addresses in the page text, then LinkedIn recruiter profiles. noreply@, press@, freemail and third-party vendor addresses are filtered out. When a company publishes nothing at all, it falls back to conventional role mailboxes — careers@, jobs@ — explicitly marked at low confidence, so a real find is never dressed up as a guess.

Then it writes the email. One per contact, grounded in the specific role and the specific resume, because the entire premise collapses if the output reads like a mail merge.

And it sends from your own Gmail, via one-click OAuth. This is not a convenience detail. Mail sent as you is SPF/DKIM/DMARC aligned, so it lands in an inbox instead of a spam folder. Replies come back to your inbox, where you would look for them anyway. There is no third-party sending domain to build a reputation for, and no "sent via" footer announcing that a robot wrote it. Sends trickle out over hours against a warm-up budget and a hard daily limit — which is also exactly why ghost screening earns its keep, since every wasted send costs a slot that a real opening could have used.

What "personalized" has to mean now

Every product in this category claims personalization. In 2026 the word is doing almost no work, because a model that has read the job description can produce something superficially tailored for free. The differentiator is what the personalization is grounded in.

TalentPing's grounding is your resume — parsed on upload, with name, location, skills, seniority, job history and target roles extracted automatically. Upload several, one per role you are targeting, and each becomes a profile with its own roles, locations, salary floor and level. Every job found is scored against all of them, and the best-matching profile is the one whose resume and cover letter actually go out.

That last detail is the point. A candidate pitching both "senior backend" and "engineering manager" is two different candidates on paper, and sending the wrong one is worse than sending nothing.

After the send, a tracker shows every message and its status. Replies are classified by intent and a suitable response is drafted, so the part of the process that actually requires a human — deciding what to say to someone who said yes — is the part you spend your attention on.

The shape of the change

The 2020s version of AI job tooling optimized for throughput: more applications, faster, with less typing. It worked, in the narrow sense that the number went up. It also made the number meaningless.

The 2026 version optimizes for the opposite thing. Fewer sends, aimed at openings that verifiably exist, addressed to people who can actually act on them, from an address that reaches an inbox. It is a worse story for a dashboard and a much better one for a candidate.

TalentPing is open source at github.com/r2st/TalentPing.

GSTBot: Feature Spotlight

Subhendu Das — Fri, 07 Aug 2026 23:09:16 +0000

What GSTBot is

GSTBot is an AI-powered GST compliance assistant for Indian SMBs. It ingests invoices by photo, PDF or Excel, extracts vendor GSTIN, invoice number, amount, tax rate and HSN code, then auto-reconciles the purchase register against GSTR-2B — flagging amount mismatches, missing invoices, duplicates and defaulting suppliers. On top of reconciliation it calculates eligible Input Tax Credit, flags Rule 37/42/43 reversals, scores supplier filing reliability, and pre-fills GSTR-1 and GSTR-3B in GST-portal-compatible JSON/CSV. Built for the businesses priced out of ClearTax Pro and Taxilla.

How it is built

Built with FastAPI, React, Vite, PostgreSQL, Redis, Celery, OpenRouter, Tesseract.

What changed

12 new commit(s) (showing the 10 most recent):

Refuse an invoice date no invoice could carry
Read the dashboard's seven months in one scan, not seven
Refuse a GSTR-2B addressed to somebody else's registration
Let a deleted invoice's number be used again
Check the codes a reviewer types, as the extractor already does
Let the loser of a supplier race keep its invoice
Look a period's suppliers up once, not once per supplier
Refuse tax charged on a taxable value of zero, which nothing was checking
Count only credit as a supplier's credit at risk, as everything else does
Judge a payment against the invoice date the row will hold, not the one sent

Try it

See it at https://gstbot.aiknol.com.

Drafted by Herald from the project record: no AI provider was reachable at generation time. Rewrite before publishing.

Making 409A Valuations Faster and Cheaper with AI

Subhendu Das — Fri, 07 Aug 2026 23:09:15 +0000

A 409A valuation is a strange product. Every venture-backed company in the US needs one, needs it again every twelve months or after any material event, and needs it to survive scrutiny from an auditor and potentially the IRS. It is mandatory, repetitive, highly structured — and it has traditionally taken weeks and cost thousands of dollars.

That combination is unusual. Most work that is both highly structured and expensive gets automated early. Valuations did not, for a reason worth taking seriously: the output has to be defensible. A number that is fast, cheap and indefensible is worth less than no number at all, because it creates tax exposure rather than resolving it.

So the interesting question is not "can AI produce a valuation faster". It obviously can. The question is what has to be true for the fast one to hold up.

N409 is a production rebuild of the 409.ai AI-assisted valuation platform, and it is built around that question.

Where the time actually goes

Ask an analyst where a 409A engagement's hours go and very little of the answer is the valuation itself. The math — Black-Scholes OPM, income, market and asset approaches — is well-defined and, once the inputs are clean, fast.

The hours go to:

Getting the inputs out of the documents. A cap table as a spreadsheet with three merged-cell headers. An income statement as a PDF export. Projections in whatever shape the founder's model happened to take. A pitch deck with the only statement of what the company actually does.
Normalizing them. Different companies name the same line item four ways.
Selecting comparables. Finding public companies that are genuinely comparable, and being able to say why.
Writing the narrative. Prose explaining the method and the judgment calls, most of which is structurally identical between engagements.

Every one of those is a task where a language model is genuinely strong and a spreadsheet is genuinely weak. None of them is the arithmetic.

The pipeline

N409's flow follows that observation directly.

Uploaded financials — cap tables, income statements, balance sheets, projections, decks — go to an AI layer that extracts and normalizes the data and selects public comparables. An R-based quantitative engine then computes the valuation: Black-Scholes OPM, plus income, market and asset approaches. The AI drafts the narrative. An analyst reviews it, overrides anything that needs overriding, and the deliverable report is drafted, edited, versioned and published as a PDF.

The division of labour is the point. AI does extraction, normalization, comparable selection and prose. A deterministic engine does the math. A human signs.

That is not a hedge. It reflects what each part is reliable at. You do not want a language model doing option pricing, because you cannot reproduce or audit a number it produced by inference. You do not want an analyst spending four hours re-keying a cap table, because that is not judgment, it is transcription. And you cannot remove the analyst, because the signature is what makes the document mean anything.

Coverage runs beyond 409A alone: ASC 718 and ASC 820, gift and estate valuations, QSBS, and EMI/CSOP for UK option schemes.

What "audit-ready" has to mean

This is where the design gets opinionated, and where most "AI does X" products in regulated work quietly fall over.

A valuation is defensible when someone can reconstruct it. Not approximately — exactly. Which inputs, which method, which assumptions, who changed what, and when. If any step of that chain is a model output nobody recorded, the whole document is weaker than a spreadsheet a human made by hand.

So the audit trail is a first-class part of the schema rather than a logging afterthought:

Every analyst override preserves the original value. The computed number does not disappear when a human disagrees with it. Both are on the record, across all the documented valuation fields.
Every AI-produced value stores its provenance — prompt version, model, anonymized inputs, outputs, and the human acceptance that let it through. "The AI said so" is not a citation. "Model X, prompt version Y, these inputs, accepted by this analyst on this date" is.
Every AI job is persisted with status, model, cost and latency, so the pipeline is inspectable as a system, not just as a result.
An immutable trail of inputs, model and state changes, with published reports retained, aligned to AICPA practice-aid expectations.

There is a privacy consequence that falls out of the same thinking. Cap tables and financials are among the most sensitive documents a company has, and they are exactly what this system ingests. Cap-table data is anonymized before it goes to any LLM, PII is redacted from logs, access is least-privilege RBAC, and everything is encrypted in transit and at rest. Sending a client's raw cap table to a third-party API because it was convenient is not a trade a valuation firm can make.

Faster reports, and what makes them fast

The report is the deliverable, and it is where "weeks" usually becomes "weeks".

N409 treats it as a versioned artifact bound to a template version: a WYSIWYG editor over the drafted narrative, PDF rendering, and full version history. Because the narrative arrives pre-drafted from data the engine already computed, the analyst's job shifts from writing a report to reviewing one — and the recalculate path lets a changed input propagate through without starting over.

The speed does not come from skipping steps. It comes from the steps that were always mechanical no longer being done by hand.

The partner channel, and why white-label matters here

Most companies that need a 409A already have a relationship with someone — their accounting firm, their cap-table platform, their equity-management provider. That relationship is the natural distribution channel, and it is a much better one than trying to acquire startups directly.

N409's architecture treats partners as a first-class channel rather than an afterthought: a partner API with white-labelled report delivery, and per-partner branding so an accounting firm can offer valuations under its own name. The roadmap for that channel — custom domains, report logo and colour, sender identity, a co-branded client portal — is explicit and in progress rather than shipped, and worth stating plainly: today the branding foundations exist and the full white-label surface is being built out.

The strategic logic is straightforward. A firm that already does a client's books is better placed to collect their financials than any vendor, and would rather deliver the valuation as its own work product than refer the client elsewhere. Making that possible is a platform decision, not a marketing one — it has to be in the tenancy model and the report pipeline from the start.

Where this is

N409 is a rebuild, and it is honest about its stage: discovery and full technical documentation are complete, and implementation is underway with the foundations in place. It is a TypeScript monorepo — valuation, web, AI, engine-wrapper and report services over PostgreSQL and Redis, with OpenTelemetry throughout and Terraform-managed infrastructure.

The bet underneath it is simple. Valuation work is not expensive because the math is hard. It is expensive because the inputs arrive as PDFs and the output has to withstand an audit. AI is very good at the first problem and completely unhelpful with the second — so build a system that uses it for the first and engineers hard for the second.

n409.aiknol.com · github.com/r2st/N409

Why Every Developer Needs an AI Assistant on Their Messaging Platform

Subhendu Das — Tue, 04 Aug 2026 00:25:15 +0000

Your AI assistant lives in a browser tab. Your actual life happens in a messaging app.

That gap is small enough to ignore most days and expensive on the days that matter. The idea arrives on a walk, the production question arrives at dinner, the "what was that flag called again" arrives in the ten seconds before your laptop wakes up. By the time you are at a keyboard with the right tab open, the thought has either been written down badly or lost.

Telechat closes the gap by putting Claude where you already are: Telegram, WhatsApp, Slack, Discord, and a local web chat — all at once, from a single Python process on your own machine.

One process, five surfaces, one memory

The multi-platform part is not a checkbox. It is the thing that makes the rest work.

Most bots are one bot per platform, which means one conversation history per platform, which means the context you built up on your phone is not there when you switch to the desktop. Telechat runs every adapter in one process against one SQLite file, so sessions, memories and history are genuinely shared. You can start a thought on Telegram at a bus stop, keep going in the local web chat when you sit down, and it is the same conversation — not a second bot that has never met you.

Set BOT_MODE=all and every surface comes up together. Set it to a comma-separated subset and only those do.

There is no webhook, no tunnel, no public URL, and no Telechat server anywhere in the path. Your conversations go from your messenger to your machine to Anthropic, and nowhere else. For a tool you will end up telling quite a lot about your work, "self-hosted" is a meaningfully different security posture from "we promise not to look".

Getting to a working bot

npm install -g telechat
telechat init

telechat init is an interactive setup that uses the Claude CLI to walk you through each platform — it opens the right pages, grabs your tokens, validates them, and writes your config. There is also telechat setup for a plain step-by-step wizard with no Claude CLI required.

If you just want to see whether any of this is worth it:

telechat web

That starts the local web chat on 127.0.0.1:8585. No bot token, no messenger account, nothing written to disk. It needs only a way to reach Claude — the Claude Code CLI, or an ANTHROPIC_API_KEY — and it tells you which one is missing if neither is there.

Two ways to reach Claude, and the choice matters for cost:

CLI mode uses the Claude Code CLI. If you already pay for a Claude subscription, there is no API key and no per-token bill.
API mode uses the Anthropic API directly. Needs a key, and works in Docker.

Group AI, without the group hating it

The failure mode of a bot in a shared room is that it will not stop talking. Every bot that has ever been added to a busy channel and removed a day later was removed for this reason.

Telechat's group behaviour defaults to restraint: it answers when mentioned or replied to, and stays quiet otherwise. /groupmode mention|all|off changes that per room, so a channel that genuinely wants an always-on participant can have one and everywhere else stays calm.

Each room gets its own conversation. The bot in your team's incident channel does not carry over context from your private chat, which is both the correct privacy behaviour and the correct usefulness behaviour — a group thread should read like a group thread, not like it is halfway through someone else's discussion.

Access is handled the same way, socially rather than administratively. /invite mints a one-tap link that grants a friend access — no user IDs to collect, no .env edit, no restart — and /invites shows who joined through yours.

Tools, MCP, and the part that stops it being a chat toy

An assistant you can only talk to is a novelty. The value shows up when it can do things, and Telechat ships a working set of tools behind slash commands:


`/code`, `/project`	Start a coding task; set the working directory
`/plan`	Two-agent multi-step planning with progress updates
`/search`, `/fetch`, `/web`	Web search, URL summarize, page browse
`/kb`	Knowledge base — upload documents, full-text and semantic search
`/imagine`, `/tts`, `/music`, `/video`	Image, speech, music and video generation
`/schedule`, `/poll`	Scheduled tasks; polls

Alongside these it speaks MCP, so any Model Context Protocol server you already run — your database, your issue tracker, your internal API — becomes something you can reach from your phone. This is the piece that turns "Claude, but on Telegram" into an actual remote control for your own systems.

Two features round it out. Memory is per-user with full-text search, recalled into every reply, so context carries across sessions rather than dying with the chat window; /remember, /recall and /forget let you manage it directly. And smart model routing picks Haiku, Sonnet or Opus by query complexity, so a one-line question does not get billed at deep-reasoning rates.

Voice messages work too: send a voice note and it answers the transcript, free via Groq's Whisper tier, no paid key required.

The bridge, which is the part nobody else has

If you use Claude Code, this is the feature worth the install on its own.

When a Claude Code session on your machine finishes a turn or stalls on a question, you get a triage card on Telegram — status first, the pending decision pulled to the top. Reply to the card and your answer is injected back into that session via claude --resume. Pick from a session list if several are running.

Turn on --approval and every Bash, Write and Edit call waits for your tap, with the call preview and Approve / Deny / Always-allow buttons on the card. Standing rules resolve the repetitive ones without asking.

Which means a long-running agent stops being something you have to babysit at a desk. It runs, it pages you when it genuinely needs a human, you answer from wherever you are, and it continues.

Who this is actually for

Telechat is explicit about its boundary: it is a single-operator tool, and in CLI mode the bot runs with your local permissions. That is the right trade for a personal assistant on your own hardware, and the wrong one for a shared corporate deployment. Knowing which of those you are building matters more than any feature on the list.

If you already use Claude and you have caught yourself wishing it were on your phone without handing your history to a third-party wrapper, that is the whole pitch.

npm install -g telechat && telechat init

telechat.fyi · github.com/telechatai/telechat

A self-hosted Claude bot whose chat history is a SQLite file I can delete

Subhendu Das — Tue, 04 Aug 2026 00:25:14 +0000

Every "chat with an AI from your phone" product asks you for the same thing: an account. Then your conversations live in a database you don't administer, subject to a retention policy you didn't write and can't audit.

I wanted the opposite trade — Claude in my messengers, with the transcript on my own disk. That's Telechat: a self-hosted Claude bot that runs as one Python process, speaks Telegram, WhatsApp, Slack and a local web chat at the same time, and stores everything in a single SQLite file.

Here's what that actually buys you, and — because "privacy-first" is a claim people make without qualifying it — where the trust boundary really sits.

Thirty seconds, no account anywhere

The fastest way to see it work skips setup entirely:

npx telechat web

That starts a chat UI on http://127.0.0.1:8585. No bot token. No messenger account. Nothing written to disk. It needs exactly one thing — a way to reach Claude, either the Claude Code CLI you already have or an ANTHROPIC_API_KEY — and if neither is there it tells you which one is missing instead of failing obscurely.

It binds to loopback. Not 0.0.0.0 with a note in the README telling you to firewall it.

The self-hosted part is the whole point

A self-hosted Claude bot runs on your machine under your account. In CLI mode Telechat shells out to the claude binary you already authenticated, so if you have a Claude subscription there's no API key and no second bill. In API mode it talks to Anthropic directly with your key.

Either way there is no Telechat server in the path. I don't operate one. There's nothing to log into, so there's nothing of yours for me to hold. Your turn history, saved memories, knowledge base, session state and cost tracking all land in ~/.telechat/bot.db:

sqlite3 ~/.telechat/bot.db .tables   # it's just a file
telechat env clean                   # and credentials are just a file too

You can read it, grep it, back it up, or rm it. That's the entire data-deletion story.

One process, four messengers

Which platforms start is one environment variable:

BOT_MODE=telegram          # the default
BOT_MODE=telegram,slack    # a comma-separated list
BOT_MODE=all               # all four

Each adapter owns its platform's quirks — Telegram's inline keyboards, Slack's thread semantics, WhatsApp's total lack of interactivity — then hands a plain string to the same invocation layer.

The payoff isn't that it saves RAM. It's that they share the store, so they share your conversation. A memory you saved from Telegram is loaded when you ask from Slack. A session you started at your desk in the web chat is on the list when you pick it up on your phone. That's only true because there is exactly one process and exactly one database.

Nothing on the internet has to reach you

This is the design decision that removes most of the attack surface, and it's easy to miss because it shows up as an absence.

The usual chat-bot tutorial reaches for a webhook. Accept an inbound HTTP request and you now need a public URL, a TLS certificate, and a reply inside the platform's timeout — which an LLM turn routinely blows past, so you need a queue, so you need somewhere to run the queue.

Telechat never accepts an inbound connection from a platform:

Platform	Transport
Telegram	Long polling
WhatsApp	Green API free tier, polled over HTTPS
Slack	Socket Mode — an outbound WebSocket the app opens
Web chat	Local aiohttp server on `127.0.0.1`

All four are outbound. No inbound firewall rule, no tunnel, no certificate to renew, nothing exposed. It works behind NAT, on hotel Wi-Fi, on a corporate network, and on a laptop that closes — when it wakes, polling resumes.

The part "privacy-first" posts usually leave out

Self-hosted is not automatically safe, and the honest version matters more than the marketing one.

In CLI mode, this bot is a remote shell. It runs claude with your authentication and your filesystem access. Anyone who can message the bot can ask Claude to read, write, or execute, bounded only by CLAUDE_CLI_PERMISSION_MODE and CLAUDE_CLI_WORK_DIR. So:

Always set an allowlist. TELEGRAM_ALLOWED_USER_IDS, WHATSAPP_ALLOWED_NUMBERS, SLACK_ALLOWED_USER_IDS. Empty means anyone who finds your bot can use it. The setup wizard warns about this and the warning is not decorative.

The allowlist is flat. Conversations and memory are keyed per user; capability is not. Everyone on that list shares one Claude auth, one working directory, and one permission ceiling. Adding a second person grants them what it grants you. This is a personal single-operator tool, not a multi-tenant deployment, and per-user isolation does not exist yet.

There's also a class of bug worth naming because it's specific to running on a machine you care about. Telechat reads links you paste, so a pasted URL is an outbound request from inside your network. A recent fix closed the obvious holes: redirects are now followed one hop at a time with every hop re-checked, and hostnames are resolved with every resolved address checked — so a public link answering 302 Location: http://169.254.169.254/ no longer reaches cloud metadata, and a hostname pointing at 127.0.0.1 no longer reaches your own services. DNS rebinding is still open; closing it means pinning connections to a vetted address, which is a larger change. That's documented rather than glossed.

If that trade-off doesn't suit you, it should be visible before you install, not after.

Install

npm install -g telechat
telechat init

telechat init walks each platform interactively, opens the right pages, grabs your tokens, validates them, and writes your config. There's pip install telechatai if you'd rather, and telechat doctor when something's off.

MIT licensed, source at github.com/telechatai/telechat. It's a small project and the security policy describes the trust boundary in more detail than most tools this size bother with — which is, I think, the least you should expect from anything you're about to hand your filesystem to.

Telechat: Feature Spotlight

Subhendu Das — Tue, 04 Aug 2026 00:24:42 +0000

What Telechat is

Telechat is a self-hosted Claude AI bot that runs on Telegram, WhatsApp, Slack, and web chat from a single process. It features a unique Claude Desktop Bridge for remote-controlling local AI sessions from your phone, smart model routing, persistent memory, coding agents, media generation, and cost tracking. Install via npm, pip, or Docker.

How it is built

Built with Python, Claude AI, Telegram Bot API, WhatsApp, Slack, SQLite, Docker.

What changed

13 new commit(s) (showing the 10 most recent):

feat(web-chat): dark mode, social sharing meta tags, and a11y pass
test(bridge): cover the commands and callbacks users actually touch
fix: escape FTS queries in the KB, and create per-chat locks atomically
fix: two bounded-collection bugs found reading the adapters
feat(health): report the write path, which nothing could read before
docs: rewrite the architecture doc to describe the program that exists
fix: stop swallowing failures without a trace
docs: add the repository conventions a contributor looks for
docs: generate a complete configuration reference, and fix two dead settings
feat(bridge): make the approval timeout a policy, not an accident

Try it

See it at https://telechat.fyi.

Drafted by Herald from the project record: no AI provider was reachable at generation time. Rewrite before publishing.