DEV Community: Masahiko Ebisuda

AI Agents Yield to Each Other in the "Break Room" — A Month in My DIY Discord Bridge

Masahiko Ebisuda — Mon, 17 Aug 2026 01:02:17 +0000

Originally published on my Substack. I'm a Microsoft MVP based in Japan, writing in English about the AI agent systems I actually run in production.

🤖✍️ This article was co-written with AI — the AI agent (Claude Code) generated the draft based on actual collaborative work with Ebisuda, who then reviewed and edited it before publishing. Before starting to write this very article, the session posted a self-introduction in the "AI break room" described later in the piece.

Introduction

This is about CCDB (Claude & Codex Discord Bridge), the open-source tool I built for running Claude and Codex from Discord.

The last time I wrote about this series was June 18, 2026 , in an article titled "Fire off tasks to Claude or Codex from your browser with one tap — how I added 'safe LAN exposure' to my DIY Discord Bridge," which covered v3.1.0.

About a month has passed since then. Before I knew it, the version had gone from v3.1.0 → v3.2.4 , and it had quietly become a different tool. Even I found myself thinking "wait, where did I leave off last time?" — so this post is a roundup of what changed over the past month. This time, it's all free.

GitHub: https://github.com/ebibibi/claude-code-discord-bridge

What is CCDB, anyway? (30-second version)

Just send a message from the Discord app on your phone, and behind the scenes the Claude Code or Codex CLI springs into action — reading and writing code, running tests, even opening a PR. It's a tool that turns Discord into a doorway for AI coding.

One thread = one AI session. You can run a new feature in thread A, a PR review in thread B, and documentation in thread C, all in parallel
Each session is isolated in its own git worktree , so running them simultaneously doesn't cause conflicts
The backend can be switched between Claude and Codex per thread via /backend

In the previous article, I described adding a feature that lets you "safely expose only the safe entry points of your own machine's API from outside, while keeping the dangerous parts closed" — that is, exposing /api/ingest externally. That's what made it possible to say "send this whole page to the AI" from a browser extension.

So what's changed since then? There are three headline items.

__ *

① AI sessions can now "see, yield, talk to, and warn" each other (v3.2.0)

This is the biggest change of the past month.

Until now, multiple AI sessions running in parallel could only post self-introductions to a shared bulletin board called the "AI Lounge (break room)." A session would post "I'm currently looking at a bug in the XXX repo," but another session reading that post couldn't actually do anything concrete about it. It was basically just talking to itself on a bulletin board.

In v3.2.0, four layers were added on top of this. And all of them are designed to be "enabled by default, dormant until sessions actually overlap" (Zero-Config).

See

GET /api/sessions returns a list of who's currently alive, where, and doing what. It even surfaces sessions that were just born, before anything has been recorded to the DB yet — because the sessions most likely to collide are exactly the ones at that moment. GET /api/threads/{id}/messages also lets you peek directly at the conversation in another thread.

Yield (Avoid)

Before starting work, a session can place an "advisory lock" reservation tag on a resource.

POST /api/claims resource: "repo:ccdb#issue-123"

If it succeeds, you get 201
If someone already holds it, you get 409 — along with who holds it and for what purpose

"Couldn't get the lock. Guess I'll do something else instead" can now happen entirely between AI sessions, without human involvement. Locks have a TTL (2 hours by default), so a dead session can't hold a resource hostage forever. This is the "cheap half" of coordination — it uses no AI calls at all (i.e., consumes no tokens).

Talk

POST /api/threads/{id}/message lets one session deliver a message directly to another live session. mode=queue waits for the other session's turn to finish, while mode=interrupt breaks in with "stop right now."

What's interesting is that the decision rule for who continues and who steps back is embedded in the shared prompt. The order is deterministic: "already committed / has a PR > still investigating" → "whoever started earlier" → "whoever has the smaller thread ID." Since both sides run the same calculation, they arrive at the same conclusion , so it never gets stuck in an endless "after you" / "no, after you" loop. Whichever session steps back always pushes its own branch first before backing off.

Be warned

The three mechanisms above all assume a session says something explicitly. This fourth one catches collisions no one declared.

Each session's file writes (Write / Edit / MultiEdit) are logged, and if two sessions write to the same file within 15 minutes , it's treated as a collision, and a warning is posted to the break room and both threads. The key point here is checking by file path, not working directory. On a single-user machine, all sessions share the same $HOME , so comparing by directory would flag every pair as colliding , making the check meaningless. I've been squashing these "looks reasonable but is actually useless" traps one by one.

Incidentally, this very article was written on top of this mechanism. The session that started writing first posted a self-introduction in the break room saying "I'm going to write an article about CCDB," checked whether any other session was touching the same repo, claimed the work, and then started writing. It's a case of writing an article about a feature using that very feature.

__ *

② Search that solves "wait, where did that conversation go?" (v3.2.1 onward)

Discord threads get auto-archived after a period of inactivity and disappear from the sidebar (hidden, not deleted). Titles are often generic too, so "which thread was that thing I did before?" tended to become a missing-persons case.

So I added two-tier search. Neither one uses a single AI token.

Tier 1: /search

CCDB already stores the "first prompt" of each session as a summary, so this is a LIKE search against that. No new storage, no re-indexing needed. Each matching thread comes with a Discord deep link , so even archived threads can be reopened with one click.

Tier 2: /search body:True (full-text search)

For when you want to find a keyword that appeared partway through a conversation , not in the first prompt. Since Claude Code writes out the entire conversation to ~/.claude/projects/…jsonl , this grep s through those files (it doesn't use shell=True ; the keyword is passed as a literal string after -- , so it can't be abused as a flag or regex). I actually validated this against 709MB across 5,400 files of real data — each query completes within 2 seconds and matches both Japanese and English.

Rather than "having the AI search," it's "using ordinary search to pull up the traces the AI already left behind." Not burning tokens is my favorite part of this.

__ *

③ Long threads can now be sent as "just the diff" (latest)

This follows on from the /api/ingest feature (sending a whole page from the browser) covered in the previous article.

Consider a case like replying to the same long Teams thread for months on end. Since CCDB is designed to spin up a new session for every ingest call, it had to resend the entire thread every time just to convey context. Sending months' worth of history every single time was way too wasteful.

So now, for each stable key the client specifies (e.g., the ID of the first message in a Teams thread), the server keeps a running summary.

Before sending, the client calls GET /api/ingest/summary?key=… to fetch the "stored summary" and "how far it's already been read (marker)"
The client exports and sends only the diff since then
The session gets full context from "stored summary + diff," and once done, updates and saves the summary

The marker advances based on the server's own ingest records, so the read position only moves forward once the summary has actually been saved. If a session fails, it can just resend the same diff without dropping any messages. And of course, if you don't specify a key, everything works exactly as before (Zero-Config).

From "send the full thing every time" to "diff plus server-side memory." It's a quiet change, but it pays off over long-term operation.

__ *

Other small improvements

Codex model/reasoning strength is now configurable : dropped the hardcoded fixed model gpt-5.4 in favor of following the Codex CLI's own default when no model is specified (so it won't silently go stale). /effort also lets you switch reasoning strength per backend
/api/spawn can now post attachments to a new thread : when watching a Forgejo issue/PR to spin up a thread, issue attachments are now carried over and visible too
(Security fix) Closed a hole in mention-only channels : fixed a path where, in channels configured to "only respond when @mentioned," a thread manually created by a human could unintentionally spawn a session
Squashed several minor parser bugs, including one where the Codex backend's progress display would get stuck showing "Running… Ns elapsed" forever

__ *

Conclusion — "running things in parallel without incidents" keeps getting more real

A month ago, things were at the stage of "made it possible to safely poke the entry point from outside." Since then:

Multiple AIs now notice each other, yield to each other, and talk it out to avoid collisions when needed
Past work can be dug back up without spending tokens
Long conversations can continue with just diffs

It's been a month that moved straight in the direction of "keep lots of AI sessions running without incidents, without a human having to watch over them."

What's fun is that this coordination feature directly powers CCDB's own development. New CCDB features get built by multiple AI sessions working in parallel through CCDB itself, exchanging messages in the break room like "I'm working on that right now, hold on a sec." There's a real sense of the tool becoming its own scaffolding for building itself, and that's the part I enjoy most.

It's all open source, so take a look if you're curious.

GitHub: https://github.com/ebibibi/claude-code-discord-bridge

I Asked the Same Question to 7 Local LLMs — Speed and Intelligence Didn't Line Up: DGX Spark Benchmarks

Masahiko Ebisuda — Sun, 16 Aug 2026 01:01:37 +0000

Originally published on my Substack. I'm a Microsoft MVP based in Japan, writing in English about the AI agent systems I actually run in production.

Local AI models keep multiplying. But comparing numbers on model cards alone doesn't tell you which one to actually use.

Does a higher parameter count mean smarter? Does MoE mean faster? If a model is popular on AI Arena, is it good for my own work? Each question offers a partial clue, but in the end you can't decide without running the same task through the models yourself.

So this time, I ran the exact same Japanese question through 7 major models running on a single NVIDIA DGX Spark. That includes NVIDIA's Nemotron 3 Super 120B-A12B, for which I actually deployed the large quantized version.

What I compared wasn't just tokens/s.

Whether the answer finished in the specified format
Whether it made claims that would be risky in real business use
What caveats it raised
Whether any model couldn't answer without changing its settings

The results didn't shake out into a clean "bigger model = better" story. One model was fast but gave an answer too risky to show a customer as-is. Another had excellent timing but dropped the instruction to provide 3 items. And one 120B model, after thinking as hard as it could, ended up with a completely empty answer field.

So which model struck the best balance for short business-style answers? And did Nemotron 3 Super prove that its 87GB of weights are worth it compared to a 23GB-class model? Below I lay out the raw measurements and every full answer, unedited.

🤖✍️ This article was co-written with AI — AI agents (Claude Code / Codex) generated the draft based on actual collaborative work with Ebisuda and real measurement data, and Ebisuda reviewed and edited the content before publishing.

📘 The infrastructure behind my workflow

Ebi Workspace — Never forgetting experimental conditions and decisions

To keep observing while only swapping out the model, you need to keep the previous conditions, raw logs, and the reasoning behind each decision in one place. I use "Ebi Workspace," a plugin compatible with Claude Code / Codex, to manage the project's current state and measurement records in Obsidian.

👉 Claude Code / Codex That Never Forgets, Never Gets Lost — Ebi Workspace

Ebi Agent Chat Relay — Driving real hardware work from Discord

I handle model deployment, measurement, and article writing from Discord through the open-source "Ebi Agent Chat Relay." It's a conversation and coordination framework that splits multiple AI sessions into separate threads, letting them run while avoiding conflicts over the same work targets.

👉 Ebi Agent Chat Relay (GitHub)

Same input, watching speed and answer quality together

I used the GB10 in a DGX Spark. The unified memory available from the OS is about 121GiB, and Ollama is version 0.32.9. I fixed the comparison conditions as follows.

temperature: 0
seed: 42
context: 8192
Max generation budget: 320 tokens
thinking: OFF
One cold run after unloading each model, followed by 3 warm runs
Primary comparison: average response time across the 3 warm runs

Optimizing each model individually toward its own recommended settings would blend configuration differences together with model differences. So I kept the primary comparison on common conditions, and only ran separate diagnostics to check the cause for any model that couldn't answer under those common conditions.

The question posed a scenario where a small or midsize business wants to adopt generative AI without sending customer data to an external cloud AI. I asked the models to list 3 tasks suited to local AI, with each item written as a single line in the form "Task name: reason / caveat," followed by a short adoption verdict at the end. I also prohibited inventing product names or law names.

Speed first: more than a 14x gap between the fastest and slowest

The warm averages ranked as follows.

Qwen3.5 35B — 1.49s, 76.27 tokens/s, followed the format
GLM-4.7-Flash — 1.94s, 64.64 tokens/s, broke the format
Qwen3.6 35B-A3B — 2.12s, 44.72 tokens/s, followed the format
GPT-OSS 120B — 8.98s, displayed answer was empty
Nemotron 3 Super 120B-A12B — 9.09s, 20.36 tokens/s, followed the format
Gemma 4 31B — 9.81s, 10.41 tokens/s, followed the format
Qwen2.5 72B — 21.68s, 4.42 tokens/s, followed the format

For short-form responses, Qwen3.5 is overwhelmingly the fastest. But looking at the actual answer shows why deciding on speed alone is dangerous.

The fastest model, Qwen3.5, also returned its risky claim the fastest

Here's Qwen3.5 35B's answer.

Customer support log analysis: zero risk of confidential data leakage / need to check the balance between processing speed and accuracy

Internal document summarization and drafting: no need to send materials externally even when they contain personal information / depends on the quality of the training data

Business rule matching system: can reference confidential internal regulations with high security / incurs initial setup costs

Adoption verdict: when handling highly confidential customer data, local AI is a valid option.

The format is clean. But "zero risk of leakage" is an overstatement. Even with local deployment, risks remain from device compromise, permission settings, logs, backups, and data being carried out. The fastest number on the clock and an answer quality you could adopt for business as-is didn't line up.

At just over 2 seconds, Qwen3.6 was the most practical for this one question

Here's Qwen3.6 35B-A3B's answer.

Using internal data: avoids the risk of customer information leakage / requires specialized knowledge to set up the environment

Internal document summarization: drafting meeting minutes where confidentiality is essential / improving accuracy requires curating training data

Handling business FAQs: responding to inquiries that include personal information / building a verification process to prevent incorrect answers

Adoption verdict: carefully weigh the balance between securing safety and operational load, and roll it out in stages.

It raised distinct caveats — environment setup, training data, and a verification process for incorrect answers — and kept its final verdict to a staged rollout. It followed the format in 2.12 seconds.

This is purely my editorial judgment on this one question, but for short, structured Japanese business answers, Qwen3.6 would be my first candidate. It wasn't the fastest, but it struck the best balance between speed and answer quality.

Nemotron 3 Super wasn't slow — its answer was long and careful

Nemotron 3 Super, added this time, is a 120B total / 12B active MoE. Its Q4_K_M quantization in Ollama measured 86.83GB. On the DGX Spark, all the weights fit onto the GPU side, and the warm average was 9.09 seconds.

Auto-generating FAQs for customer support: can learn internal knowledge and respond instantly / operate only within a scope that excludes confidential information

Drafting sales materials: generates templates from past proposals and deal records / exclude personal information from the input

Summarizing and translating internal manuals: restructures long documents into forms appropriate for each department / don't feed in documents where alteration is prohibited

Adoption verdict: it's appropriate to start with a staged pilot operation, within a scope that protects data confidentiality while achieving operational efficiency.

Among the 7 models, this was the longest and most careful answer. On the other hand, it's somewhat conservative — for instance, demanding the exclusion of personal information even though local operation is the whole premise. On raw short-answer speed alone, it loses to the 23GB-class Qwen3.6.

That said, Nemotron 3 Super's real strength lies in agentic processing, code, function calling, and long-form reasoning. You can't conclude from this one question that "loading 87GB isn't worth it." It didn't show a speed advantage in the short-answer sprint — the result points to measuring it on longer work next.

GPT-OSS thought for 8.98 seconds and left the answer field empty

GPT-OSS 120B used up the shared 320-token budget entirely on internal thinking, leaving the displayed answer empty. This isn't an API error. It's the result of all 320 generated tokens going into the thinking side.

Even raising the max generation budget to 1000 tokens, it cut off partway through the second item. Raising it to 4000 tokens finally produced a complete answer, at a warm time of 25.89 seconds and 1087 output tokens.

Handling customer inquiries: can be trained using only internal data, reducing the risk of information leakage / model updates require regular data maintenance

Automatic summarization of internal documents: can extract key points without sending confidential information externally / summarization accuracy requires tuning for business terminology

Inventory optimization simulation: runs demand forecasting and ordering plans locally / needs to periodically retrain on seasonal variation in the data

Adoption verdict: if confidentiality is the top priority, start with local AI and consider expanding in stages.

Even with the same model, not knowing the generation budget turns it into "a model that answers nothing." Model configuration is part of its performance.

The remaining 3 models' answers

GLM-4.7-Flash

Summarizing and drafting internal documents: since it contains confidential information, data leakage risk can be avoided. / If there's uncertainty about accuracy due to insufficient recognition, training adjustments on the local model are needed.

Generating FAQs from customer support history: quality is high because it can reflect internal-specific terminology and know-how.

Adoption verdict:

If data protection is the priority, it's best suited for document creation and QA tasks.

1.94 seconds is attractive, but against the requirement of 3 items it effectively delivered only 2, and the one-line-under-80-characters constraint broke down too. By speed measurement alone it ranks 2nd; by the standard of completing the task, it's a failure.

Gemma 4 31B

Looking up internal regulations: handles highly confidential material such as employment rules, to prevent external leakage / answer accuracy

Drafting customer responses: creates drafts without hiding personal information, for efficiency / securing compute resources

Summarizing technical documents: to safely analyze proprietary design documents and know-how / model optimization

Adoption verdict: recommended when confidentiality is the top priority and the operating cost is acceptable.

It followed the format. But the caveats end in bare nouns like "answer accuracy" and "securing compute resources," leaving it weak on what to actually check. "Without hiding personal information" is also a phrase that shouldn't be adopted without permissions and auditing in place first.

Qwen2.5 72B

Customer information management: strengthens data protection and privacy compliance / high initial cost

Document creation support: can handle highly confidential information / requires learning up-to-date information

Automating quality inspection: improves productivity through fast processing / requires specialized training data

Adoption verdict: suited to work where security and privacy are prioritized.

It followed the format, but at 21.68 seconds it was the slowest among the models that completed their answer this time. "Privacy compliance" can't be guaranteed by localization alone, and the answer overall stays abstract.

My conclusion: measure task completion, not model rankings

I drew four conclusions from this one question.

The fastest model doesn't necessarily return the safest answer
Even with high tokens/s, dropping the specified format means the task isn't complete
Thinking models are put at a disadvantage just by matching the generation budget, so separate the common-condition test from the recovery diagnostic
For short structured answers, Qwen3.6 strikes a good balance. Nemotron 3 Super should be re-evaluated on longer agentic work

This isn't a comprehensive ranking. There was only one question, and I didn't measure factuality, code, images, long context, or parallel load. The common conditions of temperature=0 and thinking OFF also aren't settings that draw out each model's maximum capability.

That's exactly why I kept the raw answers. Rather than stopping at "it took 9.09 seconds," I compared what it actually said in those 9.09 seconds. From there, you can pick the model that fits your own work.

Next, I'll hand the same agentic task to Nemotron 3 Super, Qwen3.6, and GPT-OSS, and compare completion rate, tool calls, and time taken. After Qwen wins the sprint, does the 87GB Nemotron come back in the long distance? That's the next thing to observe.

One thing that caught my attention in the distribution license labeling

As of August 12, 2026, NVIDIA's official Hugging Face model card points to the NVIDIA Nemotron Open Model License. On the other hand, the embedded label on nemotron-3-super:120b-a12b-q4_K_M as pulled from Ollama showed the NVIDIA Software and Model Evaluation License.

Since my use here is evaluation, I went ahead with the measurements, but before moving the Ollama-distributed build into production or commercial use, I'll double-check whether this labeling discrepancy has been resolved. I'm not drawing a legal conclusion here.

So, what did you think? You might have been surprised that even a smaller local LLM can return answers this fast and this good. They keep getting smaller and smarter. That feeling of the same hardware getting more and more capable over time is something you can only experience in an era like this one. It's genuinely fascinating.

When I Narrowed My Human Inputs Down to Just Todoist and Discord, the System Started Running Itself

Masahiko Ebisuda — Sat, 15 Aug 2026 12:32:48 +0000

Originally published on my Substack. I'm a Microsoft MVP based in Japan, writing in English about the AI agent systems I actually run in production.

AI tools have multiplied. So have agents, skills, and automation scripts.

And yet, somehow, my hands are never free. I wake up, open a dashboard, check notifications, go look at the logs for a failed job, and think, "wait, where was that process even running?" Every time I add one more automation, I add one more place I have to go check.

That was me, up until last year.

The cause was clear: I kept thinking about what to have AI do, and never once designed where I myself would touch things. So I rewrote my policy down to one line. There are only two things a human does: throw tasks into one place, and have conversations in one place. No other entry points get added.

🤖✍️ This article was co-written with AI — an AI agent (Claude Code) generated the draft automatically based on real collaborative work with Ebisuda, who then reviewed and revised it before publishing.

In this series, I share the systems I've actually built using AI as case studies — including both the ones that worked and the ones that failed.

What I Set Out to Build

What I set out to build wasn't a specific tool or a specific agent. It was the design of the surface humans touch.

The rule I settled on was just two lines.

The only human entry points are Todoist (for dropping in things to do) and Discord (for conversation)
Everything else gets pushed to the AI and scheduler side

This is the opposite of "let's have AI do a ton of work." When people try to maximize what AI can do, they end up adding more tools. More tools means more settings screens, more places logs pile up, more places you have to go check "how's it doing now." Left unchecked, the number of automated processes and the number of places a human has to go look both grow together.

So the thing I needed to decide first wasn't the scope of AI's work — it was the footprint on the human side. If you fix that footprint first, whatever overflows has nowhere to go but onto the AI side. It's a strategy of turning the design from "addition" into "displacement."

Why This Is Hard

Once you actually try it, you find that reducing entry points is much harder than reducing features. There are three reasons.

Reason 1: Entry points multiply without you ever meaning to create them

Start using a new service, and you gain one more UI for that service. Write one automation, and you gain its config file plus the logs you check when it fails. Add monitoring, and you gain a monitoring dashboard.

Each of these is, individually, the right call. Nobody sets out thinking "let's add another entry point." And yet they keep adding up. That's because the growth in entry points happens outside the scope of any single decision. By the time you notice, your morning check-in has gone from ten minutes to thirty.

Reason 2: The "last ten percent" effectively takes over everything

Say you have a process that's ninety percent automated, with the remaining ten percent needing a final human check. That's a common design, and not a bad one.

The problem is that for the sake of that ten percent, you still have to keep opening that tool. Even though the actual work time has dropped by ninety percent, the amount of mental real estate it occupies barely shrinks. That nagging "wait, I haven't checked that today" feeling is proportional to the number of entry points, not the amount of work. Raise the automation rate all you want — as long as the entry point remains, the perceived burden doesn't go down.

Reason 3: Entry points shrink only through the decision not to add

Features grow when you add them, so adding is a task you can just do. Entry points are different — there's no such thing as a task that reduces them. All you can do is take the roundabout path: decide "starting today, I won't go check this tool's UI," and then build the wiring to funnel that information somewhere else instead.

What's more, while you're building that wiring, entry points temporarily increase, because both the old route and the new route are alive at once. If you run out of steam at this stage, you end up simply having added one more entry point. I've done this more than once.

The Questions Left Standing

The policy is simple. Narrow it down to two entry points. Saying it takes three seconds.

But when you actually try to do it, some questions remain that you can't take a single step past without answering.

Where does everything you cut go? Closing an entry point doesn't make the information you used to see there disappear. Failure notifications, deadlines, pending approvals — they all need somewhere to go. Close an entry point without preparing a destination, and that's not automation; it's just choosing not to look.

What becomes invisible when you close an entry point? And how do you notice that it's become invisible? I actually caused an incident here. There was a stretch of time when I assumed a process was running, and it had quietly stopped.

Is "two" even enough to begin with? There will inevitably come a moment when it isn't. Do you add another one then, or hold the line? Without a clear criterion, you slide back into three, then four, without ever deciding to.

From here on, I'll write about the actual results of running this design, counting up everything the records show. How many processes are currently running automatically, how many times a day they execute, and how many of those runs fail. What broke as the price of narrowing down to two entry points, and how I fixed it. And, in the end, what I had to give up to hold the line at "two."

__ *

📘 The Foundation Under This System — Ebi Workspace

The "two entry points" design described in this article doesn't run on philosophy alone. Only once AI can recall on its own which project is being discussed, and can execute fixed procedures at the same quality every time, does it become possible to shrink the surface humans touch. The foundation for that is Ebi Workspace (formerly Ebi Workspace (formerly claude-workspace)). Project management, context recovery, the skill execution framework — every mechanism that appears in this article runs on top of this plugin.

I sell the actual Claude Code setup I use, packaged as a plugin.

📡 Another Foundation — Ebi Agent Chat Relay

This is the execution framework that connects Claude Code and Codex through Discord as the front door, letting multiple AI agents converse, hand off work, and coordinate with each other.

👉 Ebi Agent Chat Relay — Supporting Conversation and Coordination Across Multiple AIs

__ *

The Actual Setup — Two Entry Points, One Execution Layer, Two Exits

Here's the overall picture first. Humans touch only the two items at the top; in principle, the three below are never checked directly.

All the numbers below are actual measurements I counted on August 5, 2026, the day I wrote this article. They aren't drawn from memory or from design documents — I counted them directly from config files and databases.

Entry Point 1: Todoist — Just Drop in Things to Do

Anything I think of, anything I'm asked to do, anything with a deadline — it all goes straight into Todoist. I don't categorize it, and I don't assign it to a project. I just drop it in.

The reason I don't need to categorize is that Todoist isn't the source of truth. The source of truth for tasks lives in each project's note in Obsidian; Todoist is used purely as an intake tray for the entry point. A morning job picks up whatever's been dropped in and writes it out to Obsidian, and anything with a deadline gets aggregated into a deadline dashboard.

This was my first design decision. An entry point must never be a "place to organize things." The moment you demand organization, it becomes a chore, and any entry point that becomes a chore will inevitably be neglected. The only job an entry point is allowed to do is receive.

Entry Point 2: Discord — The Only Window for Talking to AI

The other entry point is Discord. This has effectively become my entire working environment.

My self-built OSS project, Ebi Agent Relay Chat (formerly known as claude-code-discord-bridge), maps Discord threads and Claude Code sessions one-to-one. Start a thread, and one session spins up; reply in that thread, and the same session continues. Even from the Discord app on my phone, I get a fully-featured Claude Code.

When I actually measured it, across the 33 days since July 3rd — when session records began — 557 sessions had been started (541 in just the last 30 days). That's roughly 17 a day. And interestingly, of the 557 recorded sessions, every single one had "discord" as its origin. I no longer start Claude Code by opening a terminal.

The backend breakdown also came out: 219 on Claude, 67 on Codex, and 271 from before records began. Since I can switch AI per thread, I use Claude for implementation and Codex for review, and that split happens entirely within the same single entry point. Narrowing to one entry point doesn't mean narrowing to one AI.

The Execution Layer: Claude Code and 130 Skills

Claude Code is what executes the instructions that come in through the entry points. On top of it, I've been building up "skills" — repeated tasks solidified into procedures.

The actual count is 130. Of those, 124 are ones I built myself , and the remaining 6 are links to external repositories. Fetching the weather, generating invoices, building slides, promoting articles, finishing off video metadata — once I've done a task once, I make sure it can be called as a skill from then on.

Skills matter not because they add capability, but because they lower the pressure on the entry points. A task without a fixed procedure requires the human to remember "how did I do this again" every single time, and remembering means opening documents or tools — in other words, adding an entry point. Turning something into a skill is also, in effect, closing off one entry point.

Exit 1: The Scheduler — 114 Jobs Running on Their Own

Processes that run without any human instruction are pushed onto my self-built scheduler. This is a domain governed by a written rule: "don't use cron" (I'll get to the story of how this declaration was, in practice, not fully upheld, later on).

Counting the config files: 196 job definitions (118 of them active), and 249 schedule definitions (183 of them active). Cross-referencing active schedules against active jobs, 114 jobs are actually running on a regular schedule.

Every execution record is kept in a database.

Executions in the last 30 days: 81,335
Breakdown: 80,755 succeeded / 145 failed / 435 reclaimed while still marked as running (stale)
Success rate: 99.29%
Narrowing to the last 7 days: 20,107 runs with 6 failures (99.97%)
Yesterday alone: 2,534 runs

2,534 runs in a single day means that on average, something runs automatically once every 34 seconds. Across the entire period for which records exist, the cumulative total was over 250,000 runs.

The content ranges from posting and analyzing social media, promoting articles, post-processing YouTube videos, maintaining knowledge in Obsidian, backups, health checks, deadline reminders, and even generating this very series of articles. This article itself was born from a job that fires every 7 days. It automatically picks one topic from a ledger, actually has the AI read the source files backing it, and generates a draft — all the way through.

Exit 2: Obsidian — The Second Brain Humans and AI Share

The results of every process, and the knowledge extracted from them, all get written back into Obsidian. There are 6,060 Markdown notes , and in just the last 30 days there were 1,182 commits (roughly 39 a day).

Knowledge is split into three types. There are 234 wiki entries answering "what is X," 75 KB entries answering "here's what to do when you hit this problem," and 12 ADR entries answering "why I chose this." The daily notes, my day-to-day log, cover 479 days.

This three-way split isn't a human filing hobby — it's for the AI's sake. When you have the AI recall "what did I do last time," having it search through one box with everything mixed together degrades accuracy. Splitting the boxes by the shape of the question lets the AI go straight to the right box and only that box.

What Breaks When You Narrow Down to Two Entry Points

Now for the main event. Writing only about what went well isn't useful, so here are the four things that actually broke.

What Broke #1: "Silent Failures" Become Invisible

This was the most dangerous one.

Closing an entry point means not going to check. In other words, you simultaneously close off the opportunity to notice that something has stopped working. If a process fails loudly with an error, a notification fires — but in reality, most failures are silent.

The measurements bear this out. Those 435 stale entries from the last 30 days are a case in point. Digging into them, almost all 435 had been batch-marked as terminated at the exact same timestamp on the same day (July 19, 06:49:12). In other words, they didn't fail one at a time — this is the trace of a later cleanup job sweeping up things that had been left stuck in a "running" state. No exit code was recorded. Whether a process died or the machine rebooted, nobody was watching at the moment it happened.

Since none of this was flagged as an error, if I hadn't put a cleanup job in place, these 435 records would have been stuck showing "running" forever. The anomaly never sounded an alarm as an anomaly.

I've had incidents of the same structure happen over and over. A process skips its work and exits normally (exit code 0, so it looks successful). A script written with relative paths misfires (zero targets found, so it looks successful). A limit-value config key is missing, so it runs wide open on the default (it's running, so it looks successful). None of these gets reported as a "failure."

The countermeasure was to place actively-alerting mechanisms on the exit side, in place of the entry point I'd closed.

Run a health-check job continuously, monitoring whether services are alive at all (it ran 8,697 times in the last 30 days)
Have a separate job that detects consecutive failures and notifies, plus a separate job that reports a weekly roundup
Question whether the notification path itself is dead. In fact, there was a period when the destination webhook had been deleted, and failure notifications kept getting silently dropped with a 404. A state where no notifications arrive is indistinguishable from "normal."
When in doubt, err on the side of alerting too much. The one thing you never choose is silence

If you're going to design for fewer entry points, you must add active notifications matching the number you removed. That's the bare minimum condition.

What Broke #2: Adding More Notifications Makes Notifications Stop Working

But once you start adding notifications, the opposite problem shows up.

People inevitably grow numb to a notification that fires every morning. Push an important deadline that only comes once or twice a year into a channel you've gone numb to, and you will absolutely never notice it. I actually had an incident where I failed to notice a deadline for 21 days — the kind of deadline where missing it causes real damage. The notification had arrived. It just arrived in a place that fires every day.

The lesson here was counterintuitive: a safety net doesn't get stronger the more you add. Every notification channel you add reduces the weight of each existing one. The effectiveness of the whole set gets diluted.

As a countermeasure, I introduced the concept of "tiers" for deadline notifications.

Tier 0 (things where missing them costs money or forfeits a right) gets isolated into a dedicated channel that fires only about 20 times a year. It keeps firing until I report completion
Tier 1 (monthly recurring items) goes to the normal channel, once, on the relevant day

The goal is to preserve the sense that "it fired = something's wrong." If the Tier 0 channel fired three times a day, I'd be right back where I started. So I restricted the midday and evening re-notifications to Tier 0 only. Designing notifications is not a job of designing volume — it's a job of designing silence.

What Broke #3: The One-Message-Equals-One-Process Trap

Making Discord the entry point led me straight into a trap specific to it.

Every single Discord message becomes its own new process. That means the working directory resets with every message. Even if I cd'd into a directory in the previous message, by the next message it's back to the default.

The worst part is that when a relative-path process misfires, it doesn't error out. It goes looking for a file, doesn't find it, processes zero items, and exits normally. Nothing shows up in the logs. All you get back is a report saying "done."

The countermeasure is simple, but it demands discipline.

Always write paths as absolute paths
Have every script explicitly set its working directory at the top
For long-running processes or heavy output, don't rely on stdout — write to an absolute-path log file and read it back

And rather than just writing this down as a rule, I placed it at the very top of the config file the AI reads. It's designed to be prevented on the AI's input side, not relying on human attentiveness.

What Broke #4: Even After Writing the Rule, Only the Automated-Execution Path Ignores It

This is the one that chilled me the most.

A phenomenon occurred where the AI followed the rules when instructed interactively, but violated them specifically when auto-launched by the scheduler. The cause was simple: the rule was written only in the skill's documentation, and never made it into the prompt that the automated-execution path assembles.

It behaved correctly only while a human was watching, and broke when nobody was. In an environment with fewer entry points, detecting this takes longer.

And while recounting everything to write this article, I found one more instance of the same structural gap.

The rules in my environment explicitly state: "use the scheduler for recurring execution; don't use cron." The reason is clear-cut — a process placed in cron leaves no execution history in the database, and no notification fires even if it fails. It's exactly the kind of breeding ground for "silent failures."

But when I actually checked, there was one job still surviving in cron. It was the daily backup for a certain service. It had been running since before the rule was decided, and precisely because it was running, nobody had touched it. The rule got written after the fact, and it never got applied to what already existed.

This captures the limits of what a rule can do well. A rule only takes effect on "things you're about to write." Anything that already existed at the moment you wrote the rule keeps living outside its reach unless you explicitly go audit for it. And because it's running fine, nobody's inconvenienced — until it stops.

There are two countermeasures. One is an operating rule: whenever I create a new convention, search the automated-execution scripts and embed it there too. The other is structural: separate the side that generates from the side that inspects.

As it happens, the very article you're reading right now is a product of that countermeasure. The articles in this series are generated automatically, but after generation, a separate inspection step runs. It cross-checks the body text against a list of words that must never be published (my employer's name, client names, internal hostnames, and so on), and if even a single one remains, it drops the article's status to "needs revision" and marks the job as failed.

Generate article → write body to a fixed path

↓

Inspect (a process separate from the generator)

├─ Any forbidden word remains → drop to "needs revision," fail

├─ Body was not saved → drop to "needs revision," fail

└─ Passes → notify with draft URL

The key point is that the inspection isn't left to the AI's prompt. I don't rely on "I wrote it in the prompt, so it should be followed." AI follows instructions most of the time, but there are kinds of mistakes where "most of the time" isn't good enough. Anything that would be irreversible on a life-altering scale gets turned into a mechanical constraint.

In the same spirit, I've kept only the publish button in human hands. Everything up to the draft is fully automated; publishing is human. I have no plans to automate this going forward.

So, In the End, Was "Two" Enough?

It was enough. With a condition, though.

Running on two entry points only works when the exit side has been made to actively alert, in place of the entry point you closed. Counting it up, of the 114 jobs running on a regular schedule, 20 were jobs purely for monitoring and upkeep. Health checks, failure alerts, backups, database cleanup, deadline reminders, detecting neglected projects — jobs that produce zero deliverables account for 18% of the total.

I don't consider this waste — I consider it the legitimate cost of reducing entry points. In exchange for the human no longer going to check, the system takes on the obligation to report on its own. As long as that trade is fair, this design holds together.

Conversely, I've also become clear on how to recognize the moment when I can no longer hold the line at "two." If I start opening some new tool's UI every day, that's a sign I'm losing. If not opening it makes me anxious, that means my notification design is insufficient. It's not that I added one more tool — it's that I added one more entry point. When that happens, I stop going to check the UI and instead write the wiring to funnel the necessary information into Discord.

Takeaways

Having run this design in practice, I've narrowed down the principles that remain to five.

1. Decide where you yourself will touch things before deciding what to have AI do. The former expands without limit; the latter is finite. Fix the finite one first, and the rest gets automatically pushed onto the AI side.

2. Don't demand "organizing" from an entry point. Make it a place that only receives. The moment you make categorization, prioritization, or project assignment happen at the entry point, that entry point gets neglected.

3. Add actively-alerting mechanisms matching the number of entry points you closed. A design where you no longer go check only works when it's paired with a design where the system reports to you. Do only one half, and it breaks quietly.

4. Notifications dilute as you add more. Physically split routes by importance. The sense of "it fired = something's wrong" can only be built through frequency of firing. Deliberately reserve one channel that fires only around 20 times a year.

5. For anything you absolutely need followed, guarantee it through inspection, not through the prompt. Separate the side that generates from the side that inspects, and stop the process if something trips the check. AI follows instructions most of the time, but for the things where "most of the time" isn't acceptable, put up a mechanical wall.

And what actually made the biggest difference turned out to be simply counting things. In writing this article, I measured everything for real, for the first time. I didn't know, until I counted, that there were 114 jobs alive on a regular schedule, that they'd run 81,335 times in the last 30 days, or that 100% of sessions were now coming through Discord. As for the one job left surviving in cron — if I hadn't counted, I would never have noticed it, for the rest of my life.

The most dangerous state is believing "it's running fine" without ever knowing the scale of your own system. What to automate next is better decided from actual counted results, not from a feeling.

Starting next time, I'll break down, one by one, the individual systems I've built on top of this foundation — beginning with the story of how I dropped cron in favor of a queue-based approach.