DEV Community

Running a LangGraph ReAct Agent in Production: OpenAI-Compatible API + Multi-Model Gateway + One-Line Tracing

Sangduk Yoo(duke) — Tue, 23 Jun 2026 22:57:54 +0000

Most LangGraph content stops at the notebook. You build a cute ReAct loop, it answers one question, and the article ends before the hard part: how do you actually serve this thing, swap models without a rewrite, and see what it's doing when it misbehaves?

This post walks through a small but production-shaped LangGraph deployment: a RAG ReAct agent that

exposes an OpenAI-compatible HTTP API, so any OpenAI client (Open WebUI, the openai SDK, LibreChat) can talk to it unchanged,
routes every model call through a gateway so switching from a hosted API to self-hosted vLLM is a config change, not a code change, and
gets full tracing — node transitions, tool calls, and LLM calls in one trace — by adding a single callback.

Every snippet below is real code from a working service. Roughly 150 lines of Python is all it takes.

The shape of the thing

OpenAI client (Open WebUI, openai SDK)
        │  POST /v1/chat/completions
        ▼
FastAPI router ──► LangGraph StateGraph ──► LLM Gateway ──► model (hosted API today, vLLM tomorrow)
        │                   │
        │                   └──► ToolNode ──► Qdrant (RAG)
        │
        └──► Langfuse callback (one trace per request)

The contract with the outside world is just the OpenAI API. Everything interesting — the graph, RAG, tracing — lives behind that boundary. That single decision is what lets an off-the-shelf chat UI drive a custom agent with zero adapter code.

1. The ReAct graph

The graph is deliberately tiny: one agent node that reasons, one tools node that retrieves, and a conditional edge that loops between them until the model stops asking for tools.

# app/graph/builder.py
from langgraph.graph import END, StateGraph
from langgraph.prebuilt import ToolNode, tools_condition

def build_graph():
    g = StateGraph(AgentState)
    g.add_node("agent", agent_node)
    g.set_entry_point("agent")

    # ReAct: if the model emits tool_calls, go to `tools`; otherwise END.
    g.add_node("tools", ToolNode(TOOLS))
    g.add_conditional_edges("agent", tools_condition)
    g.add_edge("tools", "agent")
    return g.compile()

tools_condition and ToolNode are LangGraph prebuilts that do the unglamorous work: inspect the last message for tool_calls, route accordingly, execute the tools, and append ToolMessages back into state. You wire the loop; they run it.

State is a single shared message log with a reducer that appends rather than replaces:

# app/graph/state.py
from typing import Annotated, TypedDict
from langchain_core.messages import BaseMessage
from langgraph.graph.message import add_messages

class AgentState(TypedDict, total=False):
    messages: Annotated[list[BaseMessage], add_messages]

add_messages is the reducer. Every node returns {"messages": [...]} and LangGraph merges it into the running log — no manual list-shuffling, and it's what makes the agent⇄tools loop accumulate context correctly.

The agent node binds the tools and calls the model. Note bind_tools is conditional — flip RAG off and the exact same node degrades to a plain single-shot chat call:

# app/graph/nodes/agent.py
async def agent_node(state: AgentState) -> dict:
    llm = get_llm()
    if get_settings().rag_enabled:
        llm = llm.bind_tools(TOOLS)
    messages = [SystemMessage(content=SYSTEM_PROMPT), *state["messages"]]
    response = await llm.ainvoke(messages)
    return {"messages": [response]}

And the tool itself is an ordinary @tool-decorated function. The docstring is not documentation — it's the prompt the model reads to decide when to call it:

# app/graph/tools.py
@tool
def search_docs(query: str) -> str:
    """Search internal docs for content relevant to the question.
    When the user asks about the project/system/docs, call this first."""
    hits = get_vector_store().similarity_search(query, k=get_settings().rag_top_k)
    blocks = [
        f"[{i}] (source: {doc.metadata.get('source', 'unknown')})\n{doc.page_content.strip()}"
        for i, doc in enumerate(hits, 1)
    ]
    return "\n\n".join(blocks) or "No relevant documents found."

Returning a [1] (source: ...) structure isn't cosmetic — it's how the model can cite sources in its final answer, which is the difference between a demo and something people trust.

2. The OpenAI-compatible surface

Here's the lever that makes everything else cheap: the agent speaks OpenAI's wire format. The router turns an incoming /v1/chat/completions request into graph input and the graph's output back into an OpenAI response.

# app/api/router.py
@router.post("/v1/chat/completions")
async def chat_completions(req: ChatCompletionRequest):
    graph = get_graph()
    inputs = {"messages": to_langchain_messages(req.messages)}
    config: dict = {}

    if not req.stream:
        result = await graph.ainvoke(inputs, config=config)
        text = extract_final_text(result.get("messages", []))
        return make_completion(text, settings.served_model_name)

    return StreamingResponse(
        graph_to_openai_sse(graph, inputs, settings.served_model_name, config=config),
        media_type="text/event-stream",
    )

Because the response matches OpenAI's schema (including SSE streaming chunks), Open WebUI thinks it's talking to OpenAI. You point its openaiBaseUrl at this service and your custom RAG agent shows up as a selectable model. No frontend work.

3. One gateway, many models

LangGraph nodes never name a provider. They call one factory:

# app/llm/client.py
from langchain_openai import ChatOpenAI

def get_llm(model=None, temperature=None, streaming=True) -> ChatOpenAI:
    s = get_settings()
    return ChatOpenAI(
        base_url=f"{s.litellm_url}/v1",   # gateway, not a provider
        api_key=s.litellm_key,
        model=model or s.default_model,
        temperature=s.default_temperature if temperature is None else temperature,
        streaming=streaming,
    )

The base_url points at a LiteLLM gateway, not at any specific vendor. LiteLLM exposes an OpenAI-compatible endpoint and fans out to whatever its model_list says — a hosted API today, self-hosted vLLM tomorrow. Migrating off a paid API to an in-cluster GPU model becomes a gateway config edit; this Python file never changes.

There's one deliberate escape hatch — when the gateway is down locally, point straight at Ollama's OpenAI-compatible endpoint:

    if s.chat_provider.lower() == "ollama":
        return ChatOpenAI(base_url=f"{s.ollama_url}/v1", api_key="ollama",
                          model=model or s.ollama_chat_model, ...)

Same ChatOpenAI class, different base_url. The OpenAI-compatible interface shows up three times in this architecture — inbound API, gateway, and local fallback — and that consistency is the whole trick.

4. Tracing in one line

A multi-node graph with a tool loop is opaque when it goes wrong. Did the model skip the tool? Retrieve garbage? Loop twice? Langfuse's LangChain callback captures the entire run — every node transition, tool call, and LLM call — as a single nested trace.

The integration is genuinely one object:

# app/obs/langfuse.py
from functools import lru_cache

@lru_cache
def get_langfuse_handler():
    s = get_settings()
    if not (s.langfuse_public_key and s.langfuse_secret_key):
        return None  # no keys → tracing silently disabled (safe for local/POC)
    from langfuse.langchain import CallbackHandler
    return CallbackHandler()

Heads-up for the SDK version churn: on Langfuse SDK v3+ the import is from langfuse.langchain import CallbackHandler, and the handler reads LANGFUSE_PUBLIC_KEY / LANGFUSE_SECRET_KEY / LANGFUSE_HOST from the environment — you don't pass keys to the constructor anymore. This tripped up a lot of v2 tutorials.

Then attach it per request via the graph config — which is also where you stamp user/session metadata so traces are filterable in the Langfuse UI:

# app/api/router.py
handler = get_langfuse_handler()
if handler is not None:
    config["callbacks"] = [handler]
    config["metadata"] = {
        "langfuse_user_id": req.user or "anonymous",
        "langfuse_session_id": getattr(req, "chat_id", None) or "no-session",
        "langfuse_tags": ["my-agent", settings.served_model_name],
    }

Passing the handler through config["callbacks"] (rather than baking it into the LLM client) means it propagates down the entire graph automatically. One request → one trace → every step visible.

What this buys you

Concern	How it's handled	Why it scales
Frontend integration	OpenAI-compatible API	Any OpenAI client works unchanged
Model choice	LiteLLM gateway behind `ChatOpenAI`	Swap providers via config, not code
Agent logic	LangGraph `StateGraph` + prebuilts	ReAct loop in ~10 lines, extensible to multi-agent
Observability	Langfuse callback via graph `config`	One trace per request, zero per-node wiring
Local dev	Ollama fallback through same interface	No gateway needed to hack offline

None of these pieces is exotic. The point is the seams: an OpenAI boundary on the outside, a gateway boundary on the model side, and a callback boundary for observability. Get the seams right and the agent in the middle stays small and swappable.

The same skeleton extends cleanly to a supervisor/worker multi-agent graph, a Postgres checkpointer for persistent threads, and an in-cluster vLLM model — each is an additive change behind one of those seams. But that's a follow-up post.

Built with LangGraph, LangChain, LiteLLM, Qdrant, and Langfuse. If you're running LangGraph in production and want to compare notes on deployment patterns, reach out.

The SaaS Churn Rate Formula: 3 Calculations That Expose Your Real Runway Risk

Doni Setiawan — Tue, 23 Jun 2026 22:57:40 +0000

This article was originally published at https://saastools.corenk.com/articles/saas-churn-rate-formula

You closed the month at $12,750 MRR. But when you opened your dashboard on the 3rd, $890 had quietly walked out the door — six cancellations, one downgrade, and two payment failures that won’t retry. That $890 won’t come back. And next month, the same silent arithmetic starts all over again. If the only number you’re tracking is a rough churn percentage from your billing tool, you are flying into a cash wall with the instrument panel switched off.

Most bootstrapped founders treat the SaaS churn rate formula as a single division problem they glance at quarterly. The truth: there are three distinct formulas, and each one tells you a different survival story. This guide will walk you through the exact calculations, give you worked examples you can steal, and show you how to read the numbers before your runway becomes a countdown. If you want the full context of why churn kills, the full churn rate overview explains the silent compounding that turns small losses into fatal ones.

How Do You Calculate Customer Churn (Logo Churn)?

Logo churn is the bluntest instrument in your financial toolkit, yet it’s the one most founders default to. The calculation is dead simple, but what it hides is far more dangerous than what it shows.

Customer (Logo) Churn Rate (%) = (Customers Cancelled ÷ Total Customers at Start of Period) × 100

Let’s say you began February with 213 paying customers. By the 28th, 14 of them cancelled. Logo churn = (14 ÷ 213) × 100 = 6.6%. On the surface, that’s a manageable fraction — until you realize that logo churn treats every customer as equal. It doesn’t care whether the customers who left were on $19/mo or $199/mo plans. It’s a headcount metric, not a money metric.

One founder I worked with, Marta, was running a bootstrapped analytics SaaS. Her dashboard showed 3.2% logo churn, and she assumed she was in great shape. The problem? Most of the cancellations were coming from her highest‑tier accounts. Her MRR was being gutted while the logo number stayed deceptively low. Logo churn is a canary — it chirps early, but you need to know which mine it’s sitting in.

What Is Gross MRR Churn and Why Does It Hit Harder?

Gross MRR churn translates the headcount loss into actual dollars — and that’s where the runway pain becomes impossible to ignore. This version of the SaaS churn rate formula accounts for both cancellations and downgrades, giving you the real revenue hole each period.

Gross MRR Churn Rate (%) = (MRR Lost from Cancellations + MRR Lost from Downgrades) ÷ Starting MRR × 100

In Marta’s case, her $12,750 starting MRR lost $960 from cancellations and another $120 from downgrades — total $1,080 in lost gross MRR. Gross MRR churn = ($1,080 ÷ $12,750) × 100 = 8.5%. That’s over two and a half times her logo churn figure. She wasn’t just losing customers; she was bleeding the revenue that kept her lights on. A downgrade from a $99/mo plan to a $29/mo plan doesn’t appear in logo churn, but it vaporises $70 every month forever. Gross MRR churn catches that.

WARNING: Logo Churn vs. MRR Churn Gap

If your gross MRR churn is consistently higher than logo churn by more than 2×, your largest accounts are abandoning you. This is the most common cause of “silent runway evaporation” — MRR drops while customer count looks flat. Every month you ignore this gap, you are burning an extra $600–$2,000 that you won’t get back.

Can Your Net MRR Churn Be Negative?

The third variant of the SaaS churn rate formula is where bootstrapped growth actually lives. Net MRR churn subtracts expansion revenue — upgrades, add‑ons, seat additions — from the revenue you lost. A positive net churn means you’re still losing ground. A negative net churn means your existing customers are out‑growing your losses; you’re expanding faster than you churn.

Net MRR Churn Rate (%) = (Lost MRR − Expansion MRR) ÷ Starting MRR × 100

In the same month Marta lost $1,080, her expansion revenue from upsells and seat additions brought in $1,730. Net MRR churn = ($1,080 − $1,730) ÷ $12,750 × 100 = −5.1%. Negative. Her churn didn’t just stop eating her runway — it became a growth engine. The expansion revenue more than covered the hole left by cancellations and downgrades. This is the state every bootstrapped SaaS should fight for: net‑negative churn turns retention math into a compounding asset instead of a liability. Baremetrics’ open benchmark data consistently shows that bootstrapped SaaS with negative net churn grow 3‑5× faster without raising a dime.

FOUNDER INSIGHT: Net‑Negative as the Bootstrapped Multiplier

ProfitWell’s retention research highlights that companies with net‑negative churn achieve median ARPU growth of 15–22% year‑over‑year from the existing base alone. For a bootstrapped founder at $15,000 MRR, that’s an extra $2,250–$3,300 a month from customers you already have — no ad spend, no launch, just expansion.

The Compound Math of Churn: A $12,750 MRR Comparison

Small churn differences don’t feel urgent in month one. By month twelve, they’ve carved entirely different futures out of the same starting revenue. The table below shows what happens to $12,750 MRR under two churn scenarios — 2% and 5% monthly — without any new customer growth. Every number assumes only the churn math is at work.

Month	MRR Remaining at 2% Churn	MRR Remaining at 5% Churn	Immediate Monthly Loss (5% vs 2%)
Month 1	$12,495	$12,113	−$382 /mo
Month 6	$11,291	$9,372	−$1,919 /mo
Month 12	$10,005	$6,890	−$3,115 /mo

At the 12‑month mark, the 5% churn scenario has eaten 46% of the original MRR — more than $5,800 gone from the monthly bank balance. A bootstrapped company running on thin margins can’t absorb that without layoffs or a cash infusion. The difference between 2% and 5% monthly churn is literally a $3,115 monthly cash gap. Every month you delay tightening retention, you trade future runway for today’s comfort.

What Is a Healthy SaaS Churn Rate Across Market Tiers?

The “good” churn number depends heavily on your customer segment. A B2C prosumer tool lives in a different churn universe than an enterprise workflow platform. Use the table below to benchmark your logo and MRR churn rates against real‑world bands, with the monthly MRR impact measured at $12,750 starting revenue. All figures come from the open benchmark datasets of Baremetrics and ChartMogul.

Market Tier	Typical Monthly Churn Rate	Monthly MRR Loss /mo at $12,750 MRR
B2C / Prosumer	5–10%	$638–$1,275 /mo
SMB	3–5%	$383–$638 /mo
Mid‑Market	1.5–2.5%	$191–$319 /mo
Enterprise	0.5–1%	$64–$128 /mo

Figures calculated at $12,750 starting MRR.

If you sell to SMBs and your gross churn sits above 5%, you are losing at least $638/month more than the upper boundary expects — and that’s before any downgrades are counted. This gap compounds into a multi‑thousand‑dollar runway reduction every quarter, so treat the benchmark as a floor pressure, not a ceiling permission.

4 Tactical Rituals to Calculate and Weaponize Your SaaS Churn Rate Formula Monthly

Knowing the formulas isn’t enough. You need a repeatable discipline that turns the numbers into action. These four rituals take less than an hour a week and have saved bootstrapped founders thousands in preventable MRR leakage.

Run the full three‑churn‑rate spreadsheet every first Monday of the month.

Pull your billing data, calculate logo, gross MRR, and net MRR churn side‑by‑side. Do this before opening your analytics dashboard — let the raw finance lead. Marta did this ritual monthly and in under 90 days spotted a 2.1× logo‑to‑MRR gap that was silently erasing $480/mo from her runway. Fixing it recovered $4,800 in annualized MRR.

Track the logo‑to‑MRR churn gap weekly.

Set up a 5‑minute Friday check: if gross MRR churn exceeds logo churn by more than 2×, you have a revenue‑concentration problem. A bootstrapped project management tool I advise caught this when two mid‑market clients downgraded in the same week — the logo rate barely moved, but MRR churn spiked to 7.8%. An emergency retention call saved $620/mo that would have vanished by the weekend.

Run a 30‑day “negative churn sprint” on at‑risk accounts.

Pick five accounts showing low engagement or a support‑ticket surge. Offer them a personalized expansion incentive — a usage‑based upgrade, a discounted annual seat addition, or a bundle. One founder I know turned a 2.8% net churn into ‑0.9% net within a single quarter by targeting six accounts, netting $1,340/month in new expansion MRR while zero additional ads were running.

Automate the math with a churn calculator as a single source of truth.

Manual spreadsheets are prone to cell‑reference errors that can misstate your runway by months. Use the free SaaS Churn Calculator to instantly compute logo, gross MRR, and net MRR churn from the same inputs. In a survey of bootstrapped founders, those who automated churn tracking reduced the average reporting error from 12% to under 2%, effectively making every runway forecast actionable instead of guesswork.

The SaaS churn rate formula isn’t three separate math problems — it’s one set of financial lenses glued together. If you’re still only tracking logo churn, you are reading the first page of a three‑page letter that tells you exactly how many months you have left. The question now isn’t whether you can calculate churn. It’s whether you will do all three calculations this month, or keep flying with the instrument panel half‑dark until the warning light is already red.

I built an open-source crypto trading bot that runs 4 exchanges from one server

GainAlgo — Tue, 23 Jun 2026 22:50:55 +0000

GainAlgo is an MIT-licensed crypto trading bot I've been building. The latest update lets it manage four exchanges from a single server and one dashboard:

Exchange	Futures (USDT-M)	Spot
Binance	✅	✅
Bybit	✅	✅
Upbit	—	✅
Bithumb	—	✅

That's 2 futures + 4 spot markets, all in one process.

Honesty first: it's not a money machine

On its own, the bot is roughly break-even. I think of it as tilling the field and standing guard 24/7 — the human still does the final harvest. Defaults are deliberately safe: every engine off, paper mode, single server. Live trading is an explicit, per-exchange opt-in.

If you came for "wake up to money piling up," this isn't that. It's a framework you tune — together.

Why one server?

Running a separate bot per exchange means juggling windows and duplicated infra. GainAlgo keeps them in one place but fully isolated:

Capital — one exchange's balance/positions never leak into another's sizing.
Records — trade journals, daily P&L, and gate stats are kept per-exchange.
Settings — entry/exit configs are tuned independently per exchange.

One screen, zero cross-contamination.

What shipping multi-exchange taught me

Before open-sourcing the latest work, I ran a multi-agent adversarial audit over the code and fixed what it surfaced:

a paper-mode path that still queried the live account,
missing order idempotency (a retry could double-fill),
per-exchange record files that could overwrite each other.

Small bot, but I'd rather knock on the bridge before crossing it.

Try it

git clone https://github.com/gainalgo/nunnaya

Copy .env.example → .env, fill only the exchange keys you use (withdrawal permission off), and run. It boots in paper mode by default — observe first.

Contribute

This is a community project — the whole point is finding good configs together. Issues, PRs, and honest teardowns are welcome.
⭐ Repo: https://github.com/gainalgo/nunnaya

How LLM Tokens Work (And Why They Explain Your AI Bill)

thestackunderflow — Tue, 23 Jun 2026 22:47:10 +0000

Your LLM never reads your words — it reads tokens. And almost every surprise on your AI bill traces back to that one fact. Here's the breakdown 👇

Here's the thing almost nobody internalizes about large language models: Claude never reads your words. It reads tokens — numbers. Your prompt is chopped into pieces, each piece is mapped to an integer, and the model only ever sees those integers. Every limit you hit, every bill you pay, and half the weird behavior you've seen traces back to this one fact.

This article explains what a token actually is, why the model works in tokens instead of words, and how that single design choice explains your AI bill.

The one-sentence version: text is split into tokens (chunks roughly ¾ of a word on average), each token maps to a number, and you pay per token — in and out — so understanding tokens is understanding cost.

What a token actually is

A token is a chunk of text — often a word, but frequently a piece of a word, a space, or a punctuation mark. The tokenizer is a fixed dictionary that maps text chunks to integer IDs.

Rough intuition:

Common words (the, code, error) are usually one token.
Rare or long words split into several tokens (tokenization → token + ization).
Whitespace and punctuation are tokens too.
A useful rule of thumb in English: ~4 characters per token, or ~0.75 words per token.

So "How tokens work" isn't 3 words to the model — it's a sequence of integer IDs like [4438, 11460, 990]. The model does math on those numbers. The English you typed was never seen.

Why models use tokens instead of words or letters

Two extremes, both bad:

Whole words: the vocabulary would be enormous and would break on any word it had never seen.
Single characters: sequences would be absurdly long and the model would waste capacity relearning how letters form words.

Tokens are the engineered middle: a fixed vocabulary (tens of thousands of entries) of common chunks that can assemble any text — including words the model has never encountered — by gluing pieces together. It's the compression that makes the whole thing tractable.

Why this explains your bill

Every API provider, including Anthropic, prices per token — and counts both directions:

Input tokens: everything you send — your prompt, the system prompt, the conversation history, retrieved documents, tool definitions. All of it.
Output tokens: everything the model generates back. Output is typically priced several times higher than input.

This is why costs surprise people:

Long context isn't free. If you stuff 50 pages into the prompt "just in case," you pay for all of it on every call.
Conversation history compounds. In a chat, each new turn resends the whole prior conversation as input. Turn 20 is paying for turns 1–19 again.
Verbose output costs more than verbose input. Asking for a 2,000-word answer is pricier than sending a 2,000-word prompt.

Your bill ≈ (input tokens × input price) + (output tokens × output price)
            └── prompt + history + docs + tools      └── the model's reply

A worked intuition

Say input is priced at $3 per million tokens and output at $15 per million (illustrative — check current rates). You send a 1,000-token prompt and get a 500-token answer:

Input: 1,000 × ($3 / 1,000,000) = $0.003
Output: 500 × ($15 / 1,000,000) = $0.0075
One call ≈ $0.01

Tiny — until you multiply by thousands of calls, or let conversation history balloon each call's input to 20,000 tokens. That's where bills come from: not one expensive call, but token count × call count.

How to reason about token cost

Count tokens, not words, when estimating cost.
Trim the prompt to what's needed. Every "just in case" paragraph is paid for on every call.
Watch history growth in chat apps — prune or summarize old turns.
Constrain output length when you don't need an essay.
Cache the stable prefix if you reuse the same big context repeatedly.

Common misconceptions

"The model reads my text." No — it reads token IDs. Your words are converted first.
"One word = one token." Often, but long/rare words split into multiple tokens, and spaces/punctuation count.
"Only output costs money." Both directions are billed; input is usually cheaper per token but there's a lot more of it.
"A bigger context window is free to use." The capacity is available; using it costs tokens on every call.

Frequently asked questions

How many tokens is a typical page of text?
Roughly 500–800 tokens per page of prose, but it varies with formatting and vocabulary.

Why do code and JSON sometimes cost more tokens than they look?
Symbols, indentation, and braces each tokenize separately, so structured text can be token-dense relative to its character count.

Does the system prompt count?
Yes. The system prompt, tool definitions, and any retrieved context are all input tokens you pay for on every call.

Is there a way to avoid resending the same big context every time?
Yes — prompt caching lets you reuse a stable prefix at a fraction of the cost.

I'm doing a whole series taking Claude apart piece by piece — video + written version of each — at The Stack Underflow. The full written companion to this one, plus the rest of the series, lives at thestackunderflow.com/tutorials.

LeetCode Like a Jedi: The Ultimate Beginner Study Plan

Timevolt — Tue, 23 Jun 2026 22:41:07 +0000

The Quest Begins (The "Why")

I still remember the first time I opened LeetCode feeling like a wide‑eyed Padawan staring at a holocron. I’d pick a problem, stare at the solution for ten minutes, copy it, move on, and then feel completely lost when a slightly different prompt showed up. It was like trying to wield a lightsaber without ever feeling the Force—lots of motion, zero impact. I knew I was grinding, but I wasn’t getting stronger. The frustration built up until I realized I was treating each problem as a isolated boss fight instead of learning the underlying patterns that connect them. That’s when I decided to change my approach and look for a single, repeatable technique that would actually stick.

The Revelation (The Insight)

The breakthrough came when I started treating every solved problem like a mini‑lesson I had to teach someone else. I call it the Teach‑Back Method: after you get a working solution, you pause, explain the algorithm out loud as if you’re teaching a five‑year‑old, and then write one plain‑English sentence that captures the core idea or pattern. That’s it. No fancy notebooks, no endless flashcards—just a verbal recap and a crisp summary.

Why does this work? Because teaching forces you to reorganize your knowledge from “I memorized steps” to “I understand why those steps exist.” When you articulate the logic in simple terms, your brain spots the invariant, the data structure trick, or the loop invariant that makes the solution tick. Once you have that sentence, you’ve got a mental hook you can reuse on future problems. It’s like leveling up your character in an RPG—each teach‑back gives you a new skill point that applies to many quests ahead.

Wielding the Power (Code & Examples)

Before: The Copy‑Paste Trap

Let’s look at a classic easy problem: Two Sum.

# Struggle version – just copying a solution I found online
def twoSum(nums, target):
    for i in range(len(nums)):
        for j in range(i+1, len(nums)):
            if nums[i] + nums[j] == target:
                return [i, j]

I’d run this, see it passed, and move on. The next day, a variant asked for “return the indices of three numbers that sum to target.” I stared blankly because I had never internalized the why behind the nested loops—I just knew “brute force works for two.”

After: Applying Teach‑Back

After solving the problem, I explained it out loud:

“We need to find two numbers that add up to a target. As we walk through the list, we can remember what number we’d need to complete the pair. If we’ve already seen that needed number, we’ve found the answer.”

That forced me to think about a lookup table. The “one‑sentence summary” I wrote down was:

“Use a hash map to store each number’s index and check for its complement while iterating.”

Now the solution looks like this:

# Victory version – pattern extracted via teach‑back
def twoSum(nums, target):
    seen = {}                     # value -> index
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:    # we’ve already seen the partner
            return [seen[complement], i]
        seen[num] = i             # store current number for future checks

The teach‑back turned a vague memory of “nested loops” into a concrete, reusable pattern: hash map for complement lookup. When I later faced the “3Sum” variant, I immediately thought, “Can I fix one number and reduce it to a two‑sum problem?”—and the same hash‑map idea guided me to a far faster solution.

Another Example: Maximum Subarray (Kadane’s Algorithm)

Before: I’d try every possible subarray, O(n²), and feel proud when it passed the small test cases.

After: I taught myself the idea:

“At each position, the best subarray ending here is either the current element alone, or the current element plus the best subarray ending at the previous position.”

One‑sentence summary:

“Keep running sum; reset to zero when it drops below zero, tracking the maximum seen.”

Code:

# Before – brute force (inefficient)
def maxSubArray(nums):
    best = float('-inf')
    for i in range(len(nums)):
        for j in range(i, len(nums)):
            best = max(best, sum(nums[i:j+1]))
    return best

# After – Kadane’s, derived from teach‑back
def maxSubArray(nums):
    max_ending_here = max_so_far = nums[0]
    for x in nums[1:]:
        max_ending_here = max(x, max_ending_here + x)
        max_so_far = max(max_so_far, max_ending_here)
    return max_ending_here

The teach‑back didn’t just give me a faster algorithm; it gave me a mental model I could apply to any “running total” problem—stock profit, longest positive streak, you name it.

Why This New Power Matters

When you internalize the why behind a solution, you stop treating LeetCode as a memorization marathon and start seeing it as a pattern‑recognition gym. Each teach‑back session deposits a reusable concept in your mental toolbox. Over weeks, you’ll notice that medium‑hard problems begin to feel like variations of themes you’ve already mastered, not alien monsters. Your confidence spikes because you’re not hoping you remembered the right trick; you know the trick because you explained it yourself.

And the best part? The technique scales. Spend five minutes after each problem to teach‑back and write that one‑sentence summary. Do that for 20 problems a week, and you’ll have built a personal cheat sheet of patterns—far more valuable than any pre‑made list of “top 100 interview questions.”

Your Turn: Start the Quest

Pick any problem you’ve solved today (or solve a new one right now). Close the editor, stare at the ceiling, and explain the solution out loud as if your rubber duck is a curious five‑year‑old. Then write one sentence that captures the essence. Post that sentence in a comment or a tweet—share your newly earned pattern with the world.

What’s the first sentence you’ll write? I can’t wait to see what patterns you unlock. Happy coding, and may the Force be with your teach‑backs! 🚀

Discrete MCP tools vs execute_code: when each wins

Bryan Clark — Tue, 23 Jun 2026 22:40:38 +0000

When we wanted our boat agents to read SignalK — wind, position, battery,
depth — over MCP, there was already a capable server for it:
VesselSense/signalk-mcp-server
(TypeScript, MIT). It's well built. Our prime directive says use existing
tools before building your own, and we take that seriously — our ship's log
is someone else's plugin
for exactly that reason.

We built a separate server anyway:
signalk-mcp. This post is
the honest version of why — because the two servers represent two genuinely
different answers to the same design question, and which one you want depends
entirely on what's driving it.

The design question

How much of the query should the model write?

VesselSense answers: all of it. It exposes a single execute_code tool.
The agent writes JavaScript, which runs in a sandboxed V8 isolate with access
to the SignalK data model. One tool definition in the context window, unlimited
query flexibility. Want the average of three battery banks, but only if the
engine is off? Write the code. No server release needed.

signalk-mcp answers: none of it. It exposes discrete, named tools —
read_sensor(path), battery_state(bank), depth_state(),
get_active_alarms() — each with a one-argument schema and a fixed response
shape. The flexibility ceiling is whatever tools the server ships.

Why execute_code wins with frontier models

If your agent is a frontier model, execute_code is hard to beat:

Token efficiency. One tool definition instead of a dozen. For long agent sessions, tool schemas are recurring context-window rent.
No n+1 round trips. A composite question ("compare house and starter bank voltage trends") is one code block, not four tool calls.
No server roadmap coupling. The model can answer questions the server authors never anticipated.

A big model writes small JavaScript correctly nearly every time. The
flexibility is real and the costs are low.

Why discrete tools win on a boat

Our target runtime is the opposite end of the spectrum: a voice assistant on
the boat, designed to run against small local models, with a text-to-speech
front-end and a sailor's attention split between the agent and the water.
Two things dominate that design, and neither is token efficiency:

1. Reliability. "What's my battery?" must work every time, in swell,
on the local model. A named tool with one validated argument is a much
smaller ask than writing correct JavaScript against a data model the agent
half-remembers. And the failure modes differ in kind: a wrong tool argument
fails loudly at the schema validator; subtly wrong JavaScript fails
quietly with a plausible-looking number. On a boat, the quiet failure is
the dangerous one.

2. A speech contract. Every signalk-mcp value carries a display string
the agent speaks verbatim — "16.5 knots", "48.8 North, 123.1 West",
spelled-out units, no symbols a TTS engine mispronounces, no radians, no
Kelvin. The server formats; the model relays. We've
written before about
why this belongs in the tool layer and not the prompt: prompt-level formatting
rules are model-dependent and leak. With execute_code, the model touches raw
SignalK values (SI units, decimal degrees, ISO timestamps) on every query, so
every query is a fresh chance to mispronounce the data. With discrete tools,
the raw values never reach the model at all.

That second point keeps proving itself. The same week we wrote this, we
watched a capable cloud model restyle a coordinate string three different
ways through three increasingly strict prompt instructions — and stop only
when the tool returned one pre-assembled sentence to relay. Models reformat
whatever they're allowed to reassemble. Tools that want deterministic output
must hand over finished strings.

So which one do you want?

	execute_code (VesselSense)	discrete tools (signalk-mcp)
Best driver	frontier model	small/local or voice-first model
Query flexibility	unlimited	fixed tool surface
Context cost	one tool schema	one schema per tool
Composite queries	one call	several calls
Failure mode	quiet (wrong code, plausible output)	loud (schema rejection)
TTS output	model formats raw values	server-formatted `display` strings
New question support	immediate	needs a server release

Neither column is "better." If you're driving SignalK with a frontier model
and want maximum flexibility, use VesselSense — genuinely. If you want
simple, reliable, speakable tools for a voice-first agent, that's what
signalk-mcp is for.

The deeper takeaway isn't about boats: tool design is model-targeting.
The same backend deserves a different MCP surface depending on who's calling.
Token-efficient power tools for big models; validated, pre-formatted,
single-purpose tools for small ones. Pick the surface for the agent you
actually run.

Adopt vs build: why we deleted our working logbook for SignalK

Bryan Clark — Tue, 23 Jun 2026 22:40:35 +0000

Our boat agents log moments by voice: "log this moment" → an entry with
position, time, and conditions. The first version of
logbook-mcp backed that
with SQLite on the agent machine. It worked. It had tests. It shipped.

Then we audited it against the SignalK logbook ecosystem and deleted the
entire storage layer.

The audit

Our prime directive is use or improve existing tools before building our
own. Applied honestly, that means auditing your own working code against
the ecosystem — not just once at design time, but again when you learn the
ecosystem better. Three candidates:

meri-imperiumi/signalk-logbook
— a semi-automatic electronic logbook that runs on the SignalK server.
Per-day YAML files, a REST API with an OpenAPI spec, a webapp in the SignalK
admin UI, and semi-automatic entries (hourly while underway, trip start/end).
The killer feature: POST /logs takes just the entry text, and the plugin
snapshots position, heading, speed, wind, and barometer from the live bus
server-side.

Saillogger — polished automatic trip capture, but your log lives in
their cloud. Wrong shape for a local-first agent that needs to read and
write programmatically.

postgsail — a
self-hosted Postgres + PostgREST + Grafana stack. Powerful trip analytics,
but a whole infrastructure tier to operate, aimed at dashboards rather than
agent-written narrative entries.

Keep ours — full control, no network dependency, no third-party risk.
But we'd be rebuilding, worse, what already exists: no UI, no auto-entries,
no enrichment — and the log would die with the laptop instead of living on
the boat.

The deciding argument

A ship's log belongs to the ship. Storing it in SQLite on the agent machine
was always slightly wrong; we just hadn't said it out loud. signalk-logbook
puts the entries on the vessel's own server as human-readable YAML — files
that remain trivially parseable decades from now even if every tool in this
post is abandoned.

That reframing also clarified what was actually ours: not entry storage,
but the agent-facing tool surface and (on the roadmap) USCG/Transport Canada
sea-time accounting — which nothing in the ecosystem does. So logbook-mcp
became ~200 lines of stateless glue: mark_moment and read_entries over
the plugin's REST API, with sea-service form export later derived from
the plugin's entries instead of kept in a parallel store. One source of
truth; the only code we maintain is the genuinely novel part.

What adoption actually cost: four undocumented quirks

Adopting someone else's plugin is not free. The OpenAPI spec got us 80% of
the way; live integration against the real server found the rest:

POST /logs returns a bare 201 with no body. You don't get the created entry back — so confirming "what did I just write?" means re-fetching the day and taking the newest entry (with a previous-UTC-day fallback for midnight races).
The "optional" ago field is mandatory in practice. The spec marks it optional; the code calls buffer.get(req.body.ago) whenever its 15-minute state buffer is non-empty, and buffer.get(undefined) throws. Send ago: 0 always.
Author attribution reads a cookie, not the Authorization header. The plugin derives the entry author from parseJwt(req.cookies.JAUTHENTICATION). Our client sends the token both ways: header for the server's auth gate, cookie for the plugin.
All /plugins/* REST routes are admin-gated. signalk-server's adminAuthenticationMiddleware guards every plugin route — device access tokens and read/write user tokens get 401 no matter what permissions you grant them. The agent's token must belong to an admin user. We verified this in the server source after two very confusing rounds of token provisioning.

None of these are complaints — they're the normal cost of integrating with
real software, and they're all documented now (in our
SPEC and
in this post, which is the writeup we wish we'd found). The total was still
a fraction of what maintaining our own store, schema migrations, UI, and
auto-entry pipeline would cost.

Where the line actually is

The audit's useful output wasn't "adopt" — it was a cleaner boundary:

Theirs: entry storage, enrichment, semi-automatic entries, the curation UI. Commodity for us; their core competence.
Ours: the agent tool surface (validated schemas, TTS-safe display strings, honest error states that never claim an unrecorded moment was logged), and the sea-time/licensing layer nothing else provides.

If you're holding working code you built before you knew the ecosystem,
the audit is still worth running. The sunk cost is real but small; ours
was one evening, and we traded a database for two hundred lines of glue
and a log that lives where it should — on the boat.

Zero Wasn't Zero

Robert Floyd Dugger — Tue, 23 Jun 2026 22:39:35 +0000

My design reviewer had been poking the same hole in my strategy for weeks. Small gaps, pointed out one at a time — the analytics weren't catching traffic well, the numbers I was quoting didn't have the resolution to support the decisions I was hanging on them. So one night I finally sat down to actually read my Google Analytics dashboard, instead of glancing at it and feeling vaguely behind. The goal was real details. Another step in the right direction.

Eight active users for the week. Four of them from Council Bluffs, Iowa.

I don't know anyone in Council Bluffs, Iowa. Google does, though — it's the site of one of their largest data centers. Half of my "users" were crawlers pinging my site and getting logged as people. So my real week was three, maybe four humans. Organic search: zero. Qualified leads: zero. Converted leads: zero.

I run a consulting intake form on that site. Multi-step wizard, dialer platforms, pain points, contact info — the funnel's entire bottom end. And here's the part I have to be honest about: when the work to wire it into analytics finally started, and the agent running the directive stopped cold to report that the intake page had never loaded the analytics tag at all — not one recorded page view, ever — I wasn't shocked. I'd been told it probably wasn't tied in. I half knew. The stop report wasn't a discovery. It was confirmation of a suspicion I'd been carrying around for weeks instead of spending ten minutes to check.

That's the actual lesson, and it's less flattering than "I found a bug." Some projects get real developmental commitment. My website isn't one of them — it gets passing attention, and known holes survive a remarkably long time in projects that only get passing attention. I prefer a clean repo the way everyone prefers a clean kitchen, and like everyone, I have a room I just don't go in.

What surprised me wasn't the hole. It was noticing what the zeros had been doing to me anyway. I knew the instrumentation was suspect — and the row of zeros under "leads" still read like a verdict every single time I glanced at it. A gauge you know is broken still lies to you, and you still flinch. "Nobody wants this" and "you never measured it" produce the exact same dashboard, and even when you suspect it's the second one, your gut reads the first.

The fix took one evening once it stopped being deferred: tag on the page, a generate_lead event on successful submission, fallback paths so analytics can never break the form itself. The funnel now reports both of its ends — views and submissions — so the two failure modes finally look different. Views without submissions means the page doesn't convert. No views means nothing sends anyone there. Opposite problems, opposite fixes, indistinguishable until this week.

Instrument the conversion point before you judge the funnel. And if you suspect a gauge is broken — confirm it today, because you're going to keep reading it either way.

Data starts now. The next zero on that dashboard will be a real one. Weirdly, I'm looking forward to it.

Análisis de APIs para agentes autónomos: patrones en Prowl

ProwlIndex — Tue, 23 Jun 2026 22:35:55 +0000

Resumen

Este artículo examina cinco APIs listadas en Prowl, todas con score n/a. Aunque no hay ranking cuantitativo, el contexto permite identificar patrones de diseño en plataformas orientadas a agentes autónomos y procesos distribuidos.

APIs analizadas

Apumail

API nativa para agentes, con capacidad de crear y leer correos electrónicos sobre un API de texto plano. Soporta content negotiation (text/plain para agentes, HTML para humanos). Esto es relevante: permite que un agente lea un correo como texto plano sin parsear HTML, reduciendo costos de procesamiento y errores.

Ejemplo de uso: un agente de customer support que revisa bandejas de entrada y responde automáticamente en base a reglas.

RogerThat

Capa de coordinación y chat entre agentes. Infraestructura de mensajería en tiempo real para sistemas multiagente. No es un simple bus de eventos; es un canal estructurado con timeouts y delivery guarantees.

Caso práctico: dos agentes, uno de extracción de datos y otro de generación de informes, coordinándose mediante mensajes de solicitud/respuesta en tiempo real.

DOBI

Agente autónomo para operaciones en el mundo físico a través de DePIN (redes de infraestructura física descentralizada) y activos del mundo real (RWAs). Ejecuta acciones on-chain. Ejemplo: un agente que verifica la temperatura de un sensor IoT desplegado en una bodega y activa un contrato inteligente si supera un umbral.

CIDIF

Plataforma para gestionar solicitudes de fondos de I+D e innovación. No es un agente per se, sino un frontend para procesos administrativos. Su inclusión sugiere que Prowl indexa herramientas de productividad no estrictamente IA.

Orquesta

Orquestador de flujos de trabajo de IA con soporte para pipelines multi-paso. Permite componer, ejecutar y monitorear cadenas de agentes. Similar a frameworks como LangGraph o Temporal, pero empaquetado como API.

Ejemplo: un pipeline que recibe un audio, lo transcribe, extrae sentimiento y genera un resumen, todo orquestado por Orquesta.

Patrones observados

Dominio de agentes autónomos. Cuatro de cinco APIs están diseñadas para agentes que operan sin intervención humana constante. Esto alinea con tendencias actuales de automatización inteligente.
API nativa, no SDK pesado. Apumail y RogerThat ofrecen APIs REST con formatos plain-text o JSON. Sin dependencias de Python o Node.js, lo que facilita integraciones ligeras.
Coordinación y comunicación. RogerThat se enfoca en la capa de comunicación entre agentes, un punto débil de muchos sistemas multiagente. Orquesta resuelve la orquestación secuencial. Ambos son complementarios.
Operaciones en el mundo real. DOBI integra blockchain e IoT, lo que indica una expansión de los agentes más allá de APIs web. Riesgos de latencia y costes de gas.
Herramientas administrativas. CIDIF es la excepción: no es un agente, sino un portal de gestión. Su presencia puede ser un ruido en el índice o una señal de que la plataforma cataloga también servicios SaaS tradicionales.

Conclusión

Las APIs más prometedoras para sistemas distribuidos son Apumail (acceso a correo optimizado para agentes), RogerThat (mensajería interagente) y Orquesta (orquestación de pipelines). DOIBI añade complejidad on-chain que puede ser excesiva para muchos casos de uso.

Hipótesis falsable: En los próximos seis meses, el uso conjunto de Apumail + RogerThat + Orquesta reducirá en al menos 30% el tiempo de implementación de un sistema de atención al cliente basado en agentes, comparado con una solución que implemente estos componentes desde cero.

# Stop Paying AI to Read Garbage Job Posts (And Help Us Build the Antidote)

Alex Seif — Tue, 23 Jun 2026 22:34:24 +0000

Let’s be honest: hunting for a tech job right now feels like screaming into a void that occasionally auto-replies with "Unfortunately, we are moving forward with other candidates."

Naturally, as engineers, our first instinct is to automate the screaming. We build scrapers. We hook them up to GPT-4. We send it 500 job descriptions a day and say, "Hey AI, tell me if I'm qualified for this Senior PHP role."

And then the OpenAI bill arrives. Congratulations, you are now unemployed and broke.

Sending entire HTML job descriptions to an LLM to evaluate is the equivalent of buying a Ferrari just to drive to the end of your driveway to check the mail. It's expensive, overkill, and frankly, a little embarrassing.

Enter Freeworld Job Finder.

The "Fail-Fast" LangGraph Engine

We are building a dual-engine, decoupled platform designed specifically to aggressively protect your API tokens while actually finding you jobs you qualify for.

Instead of a brute-force approach, we engineered a LangGraph-inspired Finite State Machine (FSM) in PHP. It acts as an elite, ruthless bouncer for your tokens:

The Career Modeler: Give us whatever messy PDF resume or random URL profile you have. We don't care. Our Skill Extractor uses a local LLM to cleanly distill it into a normalized SkillSetDTO. No LinkedIn-style forced form fields. Just raw data.
The Assessor Graph: You tell us what you want ("Principal Engineer, Remote"). Our standalone scraper library (php-jobspy) grabs the initial list.
The Gauntlet: Jobs are immediately passed through a "Fail-Fast" pipeline. If a job has a dealbreaker keyword (e.g., "Clearance Required"), it dies at Node 1 (0 tokens). If the title is "Junior Dev", it dies at Node 2 (~100 tokens).

Only the absolute highest-quality, most promising jobs survive to reach the "Deep Evaluator" Node, where we finally spend the tokens to deeply compare the job description against your extracted skill set.

You find out if you are Qualified, Overqualified, or a Mismatch, and you didn't bankrupt yourself doing it.

We Need Contributors!

We are currently building this out with a decoupled architecture (a pure PHP/Symfony Backend API and a beautiful, glassmorphic Next.js/Vite Web Portal).

If you are tired of the job-hunting grind and want to help build a ruthless, efficient, open-source pipeline that automates the nonsense, we want you. We need React/Vue wizards for the frontend, and PHP engineers who appreciate strict DTOs and pure domain logic.

Come help us automate the void. https://github.com/alexseif/freeworld-job-finder

What breaks when a Telegram founder community crosses 2,000 people

Shekhar Thathera — Tue, 23 Jun 2026 22:33:32 +0000

_
What breaks when a Telegram founder community crosses 2,000 people_
I co-founded Startup4Nation two years ago. It is a 2,000-person community of early-stage founders and students in India. Most of the conversation happens on Telegram. Some of it happens on Luma. We run founder mixers, demo nights, and an annual pitch event.
This post is about the failure modes I hit between 1,000 and 2,000 members. Not the wins. The breaks. If you are scaling a community past 1k on Telegram specifically, these are the things nobody warned me about.

Topics stop being a routing mechanism. They become a graveyard.
Under 500 members, a few well-named topics carry the conversation. People skim, find their lane, post. Past 1k, this collapses. New members do not read the topic list. They post in the first chat they see. You start the day with six "introductions" in random topics, two pitch decks in #general, and one founder asking for a cofounder in #mumbai when they are in Bangalore.
What I tried:
Pinned a welcome message in every topic with a one-line "post X in topic Y" rule.
Asked mods to redirect posts. They got tired by week two.
Set slow_mode = 60 in #general. People just moved to other topics.
What worked:
Killed topics that did not earn their place every month. I run a 30-day audit: if a topic averaged under three posts per day, it got merged or deleted. Went from 14 topics to 6. Activity per topic went up. New members could actually see the conversation.
One and only one "drop anything" topic. Called it #lounge. It is the only topic that does not require a category. Everything that does not fit #funding, #hiring, #events, #build-in-public, #mumbai, #delhi, #blr goes there. This is the single biggest relief valve in the whole group.
If you take one thing from this post, take that: pick one topic and call it the junk drawer. Naming it #lounge is fine. #random is fine. Just have exactly one.

Telegram does not give you moderation granularity. You have to fake it. Telegram has admins, and it has per-chat permissions. That is it. There is no "remove on third warning," no "slow mode per user," no "ban by join date." At 2k members with three volunteer mods, you will burn out your mods in three weeks. What I tried: Built a Python bot with python-telegram-bot. Auto-removed intro posts that did not match a template. Mods hated it because false positives were high. Added new joiners to a "trial" group for 48 hours before letting them into the main group. People hated it. Drop-off was 40%. What worked: A simple /rules command with a one-line response. New joiners get an automated DM with the rules in plain text. Most of them read it. Most of the rest get a single, polite reminder from a mod and self-correct. A weekly mod sync on Sunday at 9pm. 20 minutes. Three mods, me, agenda in a pinned message. We review (a) who is breaking rules, (b) who is doing great and should be promoted to mod-in-training, (c) what content we are missing. Without this sync the mods drift. With it, they stay. A mod queue channel that only mods see. Any reported message goes there. Mods handle them async over the week. Crucially, we agreed on a 24-hour SLA. If a mod cannot handle a report in 24 hours, it goes to the next mod. The lesson: at this scale, your tooling is not the bot. Your tooling is the meeting.
Luma helps for events. It does not help for conversation. I moved all event RSVPs to Luma around the 1,200-member mark. It was a clear win. Event pages, ticket types, waitlists, post-event emails, all solved. But Luma is not a community platform. It does not replace Telegram. The 5% of people who RSVPed on Luma and never showed up to events were the same 5% who would have ghosted anyway. And the 20% who showed up to every event without ever RSVPing on Luma were the same 20% who were already most engaged in Telegram. What worked: treat Luma as a calendar, not a community. The Telegram group is the community. Luma is the schedule. Cross-link them on every event: Luma page has the Telegram link in the description. Telegram event announcement has the Luma link pinned. Never pretend one replaces the other.
The hardest problem is not growth. It is graduating. We have about 30 founders in the group who have raised pre-seed or are at revenue. They do not need a 2,000-person Telegram. They need a private WhatsApp with 8 other founders at their stage. They also do not want to leave the community publicly. What worked for me: I never asked them to leave. I started a parallel #founders-only topic that auto-adds anyone who has raised or hit ₹10L MRR. It is opt-in. It has its own rhythm. The main group stays open and welcoming. The founders topic stays tight and useful. The mistake I almost made: turning #founders-only into a paid tier. That would have killed the whole thing. The 30 founders would have left, and the 1,970 others would have felt like the community was leaving them behind. Community is not a funnel. It is a place.
Things I would do differently if I started over Add a lurker topic on day one. Half of any large Telegram group is reading, not posting. Give them a topic where they can react without composing a message. Emoji-only responses allowed. Write a one-page community handbook before 500 members. Not a long doc. One page. Rules, topics, mod contact, how to report. Update it quarterly. Promote two members to mod-in-training at every 500-member mark. Do not promote based on activity. Promote based on the people they help in DMs. That is the actual signal. Stop chasing "engagement metrics." Daily active members in a 2k-person group will sit at 8 to 12% on any given day. That is fine. It is not a funnel. Do not optimize it into the ground. What this has to do with DevRel I am applying for Founding DevRel at Failproof. The role is to own developer community end-to-end for an AI agent company. Slack, GitHub, Luma, events, the works. If you are hiring for this kind of role and reading this: this is the kind of community I have run. Not a Discord with three regulars. A 2,000-person community with mods, topics, events, an off-ramp for the high-engagement members, and a junk drawer for everyone else. I am not a community manager who has run one meetup. I am a community builder who has hit the failure modes above and shipped fixes for them. If you want to talk, my Telegram is in my profile. Or just open an issue on the github-triage-agent repo I shipped this week. I am triaging my own DM. ***Built and shipped github-triage-agent this week — github.com/shekhar854/github-triage-agent. Small LangGraph + Claude agent that triages GitHub issues. README documents where Claude Code breaks in production. Shekhar Thathera — co-founder, Startup4Nation. Community manager, Aayo App. B.Tech CSE (AI/Data Science), IIMT College of Engineering, Greater Noida. Applying for Founding DevRel.

Four 2026 Trust Failures You Can't Out-Patch (AUR, PAN-OS, Cisco SD-WAN, PeopleSoft)

Kerry Kier — Tue, 23 Jun 2026 22:29:00 +0000

Every keynote this spring told us the same thing: AI compressed the gap between disclosure and weaponization, so the answer is to patch faster. Fine. But I went back through what actually got exploited over the last several weeks, and most of the worst of it would not have cared how fast you patched. The bugs were not clever. They were trust assumptions and missing integrity checks we have had named CWE categories for since before half of you started writing code. Here is the mechanism on four of them, with the detection you can run today.

The trust model is the attack surface (AUR, no CVE)

Around June 11, somebody adopted a pile of orphaned packages in the Arch User Repository, edited the build recipes, and turned them into credential stealers. Over 400 confirmed, more on the community lists as cleanup dragged on. There was no zero-day and no breach of Arch's own infrastructure. The official repos were never touched.

The mechanism is the insulting part. The attacker edited PKGBUILD and .install files to invoke npm during the build, pull a malicious package (atomic-lockfile), and drop a stripped Rust binary that harvests SSH keys, tokens, browser data, cloud creds, and messaging sessions. A second wave swapped npm for bun to dodge signatures keyed on the first. What got exploited was the AUR's trust model: it trusts a package's name and history over who maintains it right now, and adopting an abandoned package is a sanctioned process. Nobody broke in. They walked through a door the system holds open by design.

Triage if you run Arch:

# Foreign (AUR) packages by install date -- anything touched on/after June 11 is suspect
pacman -Qqm | while read pkg; do
  pacman -Qi "$pkg" | grep -E "^(Name|Install Date)" | paste - -
done | sort -k4

# Diff the PKGBUILD of anything recent. Treat npm/pip/cargo/bun calls with no
# relationship to the software's function as hostile:
grep -nE "npm|pip|cargo|bun" PKGBUILD *.install 2>/dev/null

# The optional eBPF rootkit pins BPF maps under these names. If they exist,
# stop trusting the host's own tooling:
ls -la /sys/fs/bpf/hidden_* 2>/dev/null

One nuance the early coverage got wrong: the eBPF rootkit is optional, root-only (needs CAP_BPF), and does not escalate privilege. It just hides the stealer after the fact. But that changes your cleanup math. If the payload ran as root, pacman -R does not clean the box -- a package manager only deletes files it knows about, and a rootkit's whole job is to not be one of them. Rebuild from clean media or do not trust the host.

CVE-2026-0257: a firewall that trusts any cookie it can decrypt (PAN-OS)

This is a security appliance failing at the one thing it exists to do. The GlobalProtect portal issues an encrypted "authentication override" cookie so users do not re-auth constantly. When the cookie comes back, PAN-OS decrypts it with its private key and then trusts the contents without verifying a signature. The CWE is 565, reliance on cookies without integrity checking.

It gets worse if the same certificate is reused for the box's HTTPS service, which is a common config, not an exotic one. An attacker connects over HTTPS, pulls the public key, and forges a cookie the firewall accepts as gospel. Rapid7 saw exploitation start May 17. Palo Alto quietly bumped the CVSS from 4.7 to 7.8 on May 29, the same day CISA added it to the KEV.

You are exposed only if both are true: authentication override cookies are enabled on the portal or gateway, and the cookie-encryption certificate is shared with another service. Check Network > GlobalProtect > Portals/Gateways > Agent > Authentication for the override setting. Mitigation is to disable authentication override or generate a certificate used only for cookie encryption and shared with nothing else. Prisma Access was also in the affected list; Panorama and Cloud NGFW were not.

Hunt your GlobalProtect logs for the PoC's tells:

# Forged-cookie sessions in the public PoC showed:
#   - cookie auth to the local admin account from low-cost hosting IPs (Vultr, etc.)
#   - source user with an EMPTY domain field
#   - endpoint_os_version: "Microsoft Windows 10 Pro 64-bit"
# Grep gateway-auth login events and validate any "Cookie" auth to local admin:
grep -E "gateway-auth.*login.*Cookie" /path/to/globalprotect.log

CVE-2026-20182: a control plane whose auth step doesn't authenticate (Cisco SD-WAN)

This one is a months-long pattern, and Cisco is wearing it. On April 20, CISA KEV-listed three Catalyst SD-WAN Manager flaws that chain into unauthenticated access: CVE-2026-20122 (incorrect use of privileged APIs), CVE-2026-20128 (storing passwords in a recoverable format), and CVE-2026-20133 (sensitive information exposure). Then on May 14 came the one that should have been the headline: CVE-2026-20182, CVSS 10.0, an authentication bypass in the SD-WAN control plane where the peering-authentication step simply does not authenticate (CWE-287). A sophisticated actor Cisco tracks as UAT-8616 hit it as a zero-day. CISA issued Emergency Directive 26-03 over it, and once PoC code circulated, researchers counted roughly ten additional clusters piling on. June added two more, including a path traversal (CVE-2026-20262) letting an authenticated attacker overwrite any file on the box.

This is the controller that pushes config across your entire fabric -- the single most privileged box in the network -- and over a few months it shipped recoverable password storage, an info leak, a path traversal, and a control-plane auth mechanism that does not authenticate. After exploiting 20182, UAT-8616 injected an attacker key into the vmanage-admin account, then logged in over NETCONF (SSH on TCP 830) and started issuing commands.

# Hunt for the attacker key injection on SD-WAN control components:
grep "Accepted publickey for vmanage-admin" /var/log/auth.log

# Then manually validate every control-connection peering event -- especially
# vmanage peering types -- from unrecognized IPs or at unexpected times.

CVE-2026-35273: the one that was actually hard (PeopleSoft)

Credit where due: this was a genuine zero-day. ShinyHunters (Mandiant tracks them as UNC6240) spent late May and early June tearing through Oracle PeopleSoft via CVE-2026-35273, an unauthenticated RCE in the Environment Management component of PeopleTools 8.61 and 8.62, rated 9.8. Mandiant dates exploitation to May 27 through June 9. Oracle's out-of-band advisory did not land until June 10 -- the whole campaign ran before there was anything to patch. Mandiant notified 100+ orgs; 68% were higher ed. CISA KEV-listed it June 12.

Post-exploit, they dropped MeshCentral agents masquerading as Azure services (C2 at azurenetfiles[.]net), ran a *_fanout.sh lateral-movement/defacement script, and exfiltrated with zstd.

# Breach marker dropped into PeopleSoft web/app directories:
find / -name "README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT" 2>/dev/null

# Compensating controls (Oracle/Mandiant guidance):
#   - Disable the Environment Management Hub (EMHub) service, or remove PSEMHUB
#   - Block external access to /PSEMHUB/* and /PSIGW/HttpListeningConnector
#   - Watch outbound SMB (TCP 445) from PeopleSoft hosts to external destinations

The pattern: you can't patch a broken assumption

Now the macro picture, because it is the actual argument. Per Verizon's 2026 DBIR, the median time to fix a known-exploited vulnerability went up year over year, 32 days to 43, and the share fully patched fell from 38% to 26%. Rapid7's 2026 report logged a 105% jump in confirmed exploitation of high- and critical-severity flaws (71 cases to 146), and the disclosure-to-weaponization window that CSA and the Zero Day Clock now measure in hours used to take weeks. Offense compresses, remediation expands, and yes, AI compressed the discovery-and-weaponization side. That part is real.

But look at what it bought the attackers in these four. None of them was a speed problem at root. You cannot patch your way out of a package trusted because the system likes its name, a firewall that trusts any cookie it can decrypt, a control plane whose auth step does not authenticate, or an ERP endpoint left facing the internet. And in two of them -- Cisco's 10.0 and the PeopleSoft RCE -- the attackers were already inside before a patch existed at all. You cannot out-patch a clock that started before the vendor knew.

"Patch faster" is not wrong so much as beside the point. These were design failures we agreed to ship, and no amount of velocity downstream fixes a broken assumption upstream. The window did collapse. The bugs that walked through it did not need it to.

What is the worst trust-by-default you have found still shipping in a box you were told to trust? I want the examples.

Originally published at blog.vertexops.org.