DEV Community: Ekioo

A tool you use shapes itself through use

Ekioo — Fri, 21 Aug 2026 07:04:36 +0000

A week ago, I shipped KittyClaw - my local kanban for driving AI agents. Since then, I've been using it every day, across multiple projects, with multiple agents. In a week, the tool has changed.

No refactor. No "v2". Just a handful of features added along the way, each born from a real friction I didn't even know existed until I started using the thing.

Here's what strikes me looking back at this week: a tool you make yourself grows differently from a tool you put up with. I think that deserves its own article.

This piece documents KittyClaw, the kanban orchestrator at the center of the Ekioo agent-fleet R&D. Alongside Bloomii (constructive-journalism media) and Kalceo (regulatory B2B SaaS for construction contractors), KittyClaw runs the AI agents that drive these projects in production.

The "friction → feature" cycle got absurdly short

Let me give you a concrete example.

Monday, I create a ticket to rebuild the water system on Aekan. It quickly becomes clear it's too big - my programmer and technical-artist agents need to split the work. I start creating multiple tickets linked via #42 in descriptions. Except the agent loses the thread, and so do I.

Tuesday, I have sub-tickets.

Not because they were on a roadmap. Not because a request bubbled up from a backlog. Because I needed them the day before, the code is mine, and it took me a few hours to add them cleanly.

In SaaS land, this same need would have ended up on a community forum, been aggregated with 50 other similar requests, waited a quarter to reach under consideration, then maybe a year before landing in prod. Or never.

The ratio of "need detected → feature shipped" went from months to hours. That changes everything.

The "too small" features finally exist

Here's the second thing this week revealed: there's an entire category of features that didn't exist anywhere - not because they're useless, but because they're too small for a vendor to bother with.

Example: a Ctrl+Z that undoes the last action on the board.

It's one of the most useful features I've added this week. It literally does one thing: when you mess up on a ticket, you hit Ctrl+Z and it's reversed. Accidental move, wrong priority, sub-ticket dropped in the wrong place - all undone.

A few tools do it partially (Linear has an undo toast on some actions, Trello too on drag-and-drop), but rarely in a fully keyboard-driven, cover-everything way. Why? Because it's too small to justify a roadmap item, and too diffuse to be a marketing argument. But when you use it yourself, it's the difference between "I move tickets without thinking" and "I'm careful with every click".

Psychologically, it's huge. And it's exactly the kind of feature you only get in tools you make for yourself.

The tool knows things I didn't

Another weird observation from this week: my agents surfaced bugs I'd never have found on my own.

One agent created a ticket with "status": "InProgress" instead of "In Progress". The ticket ended up in a ghost column. Another sent comments with an empty author - "null created the ticket" in the activity log.

These are cases I'd never have triggered as a human user. But an agent, which reads the docs fast and tests everything, finds them in a day.

Result: I added silent validations I'd never have written if I'd stayed the only user. The API became more robust because it was tested by agents before being tested by humans.

It's an interesting inversion: agents are my best QA.

The quiet satisfaction of fixing your own bugs

There's also something I hadn't anticipated and want to mention honestly: the emotional satisfaction of fixing your own annoyances.

When you hit a bug in a paid SaaS, what do you do? You report it, you wait, you forget. The irritant persists and ruins your mood every time you hit that part of the workflow.

When you hit a bug in your own tool, you fix it. On the spot. And every time you hit that part of the workflow after, you think "oh right, I fixed that".

That small repeated satisfaction, accumulated over a week, actually affects the energy you bring to your other projects. It's not an argument you see often, but it's real.

What it says about our relationship with tools

I think we're living through an interesting moment. For twenty years, we've outsourced our tooling to SaaS vendors who decide what we can do, at what pace, and at what price. We've learned to live with "almost good" tools that never do exactly what we want, because building our own seemed too expensive.

That cost is collapsing. Not only thanks to AI agents - but through the combination of better stacks, solid templates, and agents that speed up the "writing code" phase by 5-10x.

What this means concretely: custom tools are becoming economically rational again for needs that, yesterday, would never have justified the cost.

KittyClaw is a kanban. There are dozens on the market. But none of them is exactly what I need, and none ever will be - because my need is too niche for their roadmap. So I'm making it myself, and sculpting it week by week.

In summary

This week, KittyClaw gained: sub-tickets, a dedicated sub-kanban, a global Ctrl+Z, and three silent validations. Nothing revolutionary on its own. But each addition solved an irritation I would never have seen fixed in a third-party tool.

And maybe that's the real point: once you start making your own tools, you realize how many compromises you were accepting without noticing.

The code

Everything is up to date on GitHub:

→ github.com/Ekioo/KittyClaw

If this approach resonates - or if you're also building custom tools for your workflow - join me on Discord.

→ Join the Discord

From kanban to harness: when the tracking tool becomes the orchestrator

Ekioo — Fri, 21 Aug 2026 00:02:26 +0000

When I shipped KittyClaw two weeks ago, the tool did one thing: serve as a board. The Claude agents ran alongside - first by hand, then via a dispatcher.mjs: a Node script polling KittyClaw's API, triggering the right agent based on who was assigned to which ticket.

The dispatcher worked great. It orchestrated Aekan's 13 agents for weeks. But it was an external process: one more node dispatcher.mjs to launch, a state file (dispatch-state.json) to keep in sync, logs to dig up in .agents/channel/debug.log, a config to copy-paste across projects in JS.

Today, the dispatcher doesn't exist anymore. Orchestration lives inside KittyClaw. I run dotnet run on KittyClaw, nothing else. Aekan's 13 agents still run - but the infra that drives them is now a first-class citizen of the board.

This shift from "dispatcher on the side" to "dispatcher inside the board" is small in lines of code, but it completely changes what the tool is. And how I work.

Before: two processes to run, two places to look

The old setup was three stacked layers:

KittyClaw - the board, with its UI and REST API.
dispatcher.mjs - a separate Node script in the project's .agents/channel/, launched manually in a terminal.
Claude Code - the agents themselves, launched by the dispatcher.

It worked. But every project had its own dispatcher.mjs, usually forked from Aekan and hand-adapted. Patterns duplicated: 30s polling, code lock, evaluator debounce, daily budget. Adding a feature (say boardIdle or subTicketStatus) meant re-coding it in every dispatcher, or accepting that one project had it and others didn't.

And visually, orchestration was invisible from the board. To see an agent's live activity, I'd pop a terminal, tail -f the dispatcher log, cross-reference with the board. Two places, two vocabularies.

The board didn't know there was a dispatcher. The dispatcher showed nothing on the board. They talked through the API and a JSON file - fully functional, but decoupled to the point of not knowing each other.

The click: the dispatcher belonged inside KittyClaw

What pushed me over was the pile-up of small repeated frictions. Every new project, I duplicated dispatcher.mjs. Every useful feature (like Lain's CEO wake on idle board), I'd ask myself "do I back-port it to Aekan?". Every bug, "which of the three dispatchers is running this one?".

And above all: KittyClaw already had all the info. Tickets, assignments, columns, members flagged as agents, history. The dispatcher only re-read what the board already knew, to decide what to launch. Duplicated reasoning, not data.

If it's repetitive across projects, it belongs in the engine. If the board already knows the state, it's the best-placed thing to react.

After: the board is the orchestrator

The new workflow is one step:

I create a ticket on the board, assigned to @programmer.

That's it. Thirty seconds later, KittyClaw sees the ticket in the Todo column with assignee programmer, moves it to InProgress, and launches Claude Code with the programmer.md skill and the ticket context. Outputs stream into a live run panel. When the agent finishes, the ticket is ready for review.

What makes this workflow possible is an automations.json file in the project workspace:

{
  "trigger": { "type": "ticketInColumn", "columns": ["Todo", "InProgress"],
               "assigneeSlug": "programmer", "seconds": 30 },
  "actions": [
    { "type": "moveTicketStatus", "to": "InProgress" },
    { "type": "runClaudeSkill", "skillFile": "skills/programmer.md",
      "concurrencyGroup": "code", "maxTurns": 200 }
  ]
}

No magical engine. It's a 30s poll that reads the board, matches a pattern, and launches a claude process with the right skill and context. But once it's in place, I'm no longer in the loop. I become a supervisor.

What changes mentally

The time saved is real - no more switching, no more sessions to locate, no more commands to retype. But the real shift is elsewhere.

With the external dispatcher, I'd already moved past one-on-one chat. The board + dispatcher formed a running team. But the whole thing was fragmented: I watched the board to decide, a terminal to see what agents were doing, logs to debug. Three views for one system.

Now, the board is the system. I see global state, I assign, I let the infra dispatch, I watch streaming runs from the ticket itself. On Aekan, 13 agents run like this - including a documentalist that wakes on every commit, a code-janitor that sweeps every day at 3am, and an evaluator that checks quality whenever a ticket hits Done.

I no longer manage conversations. I manage a queue.

This metaphor shift looks trivial but runs deep. You can't hold 13 simultaneous conversations in your head. You can easily supervise a 50-task queue if the tool shows you what matters.

What stays on me

I read too many threads about "AI will do everything for me", so let me be clear: what matters is still what I do.

Deciding what's worth doing.
Writing a ticket clear enough for the agent to understand.
Reviewing what comes out, accepting or pushing back.
Spotting patterns worth automating.
Sculpting the tool when it rubs.

What integration removes is exactly what had no added value: maintaining one dispatcher per project, correlating three views, manually back-porting a feature from one project to another. What it leaves is all the rest - which is precisely the interesting work.

Why this lives in the board and not elsewhere

One could imagine a separate tool: a dedicated orchestrator that reads Jira/Linear tickets and launches agents. I had that hesitation moment. But the board already knows who's an agent, who's human, the state of tickets, who's blocked, who's ready for review. Pulling that info into another tool duplicates a source of truth - and creates two places to keep in sync.

Putting orchestration in the board is recognizing that the board is already the execution plan. All that was missing was the executor.

Experience-wise: when an agent runs, stream events (tool calls, file edits, tokens burned) land in a panel that opens from the ticket. No separate tab, no separate dashboard. The board is the dashboard.

What integration unlocks

Some automations already existed inside dispatcher.mjs - documentalist on commit, evaluator on Done transition, daily code-janitor. What integration into KittyClaw changes isn't their existence, it's their reach:

One feature = all projects. When I added boardIdle for Lain's CEO wake, Aekan and HolybotsRisingApps got it for free. With three separate dispatchers, I'd have back-ported by hand.
Centralized daily budget. cost-log.jsonl is read by the single engine, the threshold (dailyBudgetUsd: 70) blocks everything non-CEO once crossed. Doing this across three independent dispatchers would have meant three implementations kept in sync.
Hot reload. POST /api/projects/{slug}/automations/reload - I change a field in automations.json, it's live. No Node process restart.
Unified observability. Every run is an engine object, accessible via API, streamed into the ticket's panel. No more tail -f on three log files.

The right way to put it: the same behaviors, but as infra instead of scripts.

What's next

The next post dives into the technical anatomy: what exactly happens between the moment I create a ticket and the moment Claude starts working. What context gets injected, how sessions persist across runs, how concurrency groups keep two agents from stepping on the same files.

But the deep lesson is already here: a board isn't a tracking tool. It's an execution plan that was waiting to be plugged in.

The code

Everything is on GitHub:

→ github.com/Ekioo/KittyClaw

If you're building custom tooling around your agents, or want to discuss this approach, join me on Discord.

→ Join the Discord

Anatomy of a ticket that runs itself

Ekioo — Thu, 20 Aug 2026 00:03:52 +0000

In the previous post, I told how KittyClaw shifted from passive board to orchestrator. Create a ticket, thirty seconds later Claude is on it. This post goes into the detail: what happens in between?

I'll follow a ticket from creation to execution, stopping on the five design decisions that make the system robust - or that saved it when it wasn't yet.

1. The trigger: polling, not webhooks

When the ticket is created, nothing happens right away. KittyClaw doesn't "react" to the creation event - it looks at the board every 30 seconds and decides what to do.

{
  "trigger": {
    "type": "ticketInColumn",
    "columns": ["Todo", "InProgress"],
    "assigneeSlug": "programmer",
    "seconds": 30
  }
}

I hesitated one evening between polling and events. Events are "cleaner" (no latency, no wasted CPU). But polling has three advantages I found decisive:

It survives anything. The engine crashes, restarts, misses an event - next tick, it catches up.
It's naturally rate-limited. Even if I create 50 tickets at once, dispatch happens in 30s windows. No thundering herd.
It's the same model as the old dispatcher.mjs I was replacing. Zero regression risk.

For rare events (a git commit, a Done transition) I have specialized triggers (gitCommit, statusChange) that poll at 60s or 30s. For events you can't afford to miss, I have boardIdle and agentInactivity that watch for absence of activity - impossible to model as events.

Rule of thumb: when in doubt between polling and webhooks in a solo-dev system, pick polling. You debug with a log file and sleep 30, not ngrok plus a retry stack.

2. Conditions: a gate before dispatch

Not every ticket matched by the trigger is dispatched. Between trigger and action sits a list of conditions to pass:

{
  "conditions": [
    { "type": "minDescriptionLength", "length": 50 },
    { "type": "labels", "labels": ["release"] }
  ]
}

On HolybotsRisingApps for example, the publisher automation fires only if the ticket carries the release label and either app:borne or app:gamemaster. The developer only takes tickets with descriptions of at least 50 chars - to keep a hastily-thrown "fix the bug" ticket from dispatching before the producer grooms it.

Conditions are the right place to encode board quality policies. They don't replace human judgment, but they kill 80% of the cases where I'd launch an agent for nothing.

3. Injected context: minimal, deliberately

When dispatch fires, KittyClaw launches a claude process with a prompt. The prompt is a lot simpler than you might expect:

{contents of skills/programmer.md}

Focus on ticket #42: {ticket title}

That's it. No description, no comments, no sub-tickets, no repo context.

Why so little? Because the agent already has the tools to fetch them. It can hit the KittyClaw API (GET /api/projects/{slug}/tickets/{id}), read comments, mentions, linked tickets, sub-tickets, on demand. And it runs inside the project's WorkspacePath - it can git log, read files, do its own research.

Every piece of context you stuff into the prompt is context you pay for in tokens on every run, including when it's not needed. Letting the agent fetch on demand is 10× cheaper and 10× fresher.

The skill file (skills/programmer.md) contains the craft rules: how to read a ticket, how to post comments, how to handle sub-tickets, when to push back for review. It's the persona - stable, versioned in the repo, editable without touching KittyClaw's code.

4. Sessions: memory between runs

If I re-dispatch the same agent to the same ticket ten minutes later, I don't want it starting from zero. It must remember what it read, did, concluded last run.

Claude Code supports --resume <session-id> natively. KittyClaw hooks into that:

var existingSessionId = _sessions.GetSessionId(workspace, agentName, ticketId);
var sessionId = existingSessionId ?? Guid.NewGuid().ToString();
var isResume = existingSessionId is not null;

The key is (workspace, agent, ticket). Each combination has its own persistent session, stored in .agents/channel/dispatch-state.json. When the agent comes back to the ticket, it's --resume and the prompt becomes:

The owner has posted feedback on ticket #42: {title}
Read ALL owner comments on this ticket and address them.

No need to resend the skill - it's in the session. You just tell it: "come back, there's new input, take a look".

Point that cost me a morning: sessions must survive KittyClaw restarts. I started keeping them in memory, then a dotnet watch nuked them all. Since then everything is persisted to disk immediately, in the same JSON file the old dispatcher.mjs used. Bonus: my projects still running on dispatcher.mjs can migrate without losing sessions.

5. Concurrency: keeping agents from stepping on each other's files

Real problem: if programmer and 3d-artist run at the same time on the same repo, they collide. Two processes editing files, a git status that no longer knows who did what.

Solution: concurrency groups.

{
  "actions": [{
    "type": "runClaudeSkill",
    "skillFile": "skills/programmer.md",
    "concurrencyGroup": "code",
    "mutuallyExclusiveWith": ["producer-commit"]
  }]
}

Rules are simple:

concurrencyGroup: at most one active run per group. Every agent that touches code sits in "code" - programmer, 3d-artist, technical-artist, qa-tester, documentalist, code-janitor. One at a time.
mutuallyExclusiveWith: while one run is active, it blocks the listed groups. HolybotsRisingApps' producer-commit, which commits/PRs a finished ticket, blocks code, producer, and publisher - because it needs a stable repo to commit cleanly.
Implicit dedup: no two active runs on (agent, ticket). If you post a comment while a run is live, it'll be picked up next poll, not in parallel.

These three rules eliminated 100% of the file-conflict issues I used to see with the old JS dispatcher. Not because the JS was bad - because the concurrency rules lived in if/else code instead of being declarative.

6. The budget: the fuse you hope never blows

Last piece, optional but precious:

{
  "dailyBudgetUsd": 70
}

KittyClaw tracks run cost (via the cost-log.jsonl Claude Code emits natively). As soon as the day's sum crosses the threshold, all non-CEO dispatches are blocked. Only a supervising agent, if any, can still run to decide what to do.

I've never hit this threshold in normal conditions. But I hit it once because of an infinite loop between two agents ping-ponging comments at each other. The budget cut out at $70, I woke up the next morning with a manageable bill and a lesson learned. Without the budget, it could have been much worse.

Recap: the full cycle

What actually happens, in order, when I create a ticket:

t = 0s: I create the ticket via UI or API. Status Todo, assignee programmer.
t ≈ 15s: the next ticketInColumn tick (poll every 30s) spots the ticket.
t ≈ 15s: conditions are evaluated (description length, labels). All pass.
t ≈ 15s: the moveTicketStatus action flips the ticket to InProgress.
t ≈ 15s: the engine checks concurrency groups. Nobody's on code - go.
t ≈ 15s: session lookup. No existing session for (workspace, programmer, #42) - new session created.
t ≈ 16s: claude process launched with --print --verbose --output-format stream-json --session-id <uuid>, prompt = skill + focus.
t ≈ 17s: stream events (assistant, tool_use, tool_result) flow into the run panel, visible from the ticket.
t ≈ N minutes: Claude is done. It posted comments, maybe created sub-tickets, maybe moved the ticket to OwnerReview. The run is logged with its cost.
t = N + 30 min of silence on Done: if the ticket moves to Done and stays quiet for 30 min, the evaluator wakes up and reviews.

This pipeline is broadly what I had before in JS with dispatcher.mjs. But:

It's declarative (automations.json) instead of imperative (code).
It's integrated with the board (runs are visible from tickets).
It survives crashes (sessions and state persisted).
It applies to every project at once (one engine, N configs).

What this teaches me about automation

The more automations I add, the more I realize the right granularity is neither "code everything" nor "configure everything". It's a collaboration between:

A simple, generic engine in code. A handful of trigger types, action types, concurrency and sessions.
Declarative per-project configs. That's where policy lives: who dispatches when, who has what budget, who blocks whom.
Skills in Markdown, versioned in the project repo. That's where persona and craft live.

The engine knows nothing about video games, docs, or CI. The skills know nothing about polling or concurrency groups. Configs bind the two.

This separation makes adding a new agent trivial: write a skill, add 10 lines to automations.json, live. No deploy, no restart - the POST /api/projects/{slug}/automations/reload endpoint does it hot.

What's next

On Aekan, 13 agents run on this system. On HolybotsRisingApps, 6 - including a specific release workflow (publisher gated by label, producer-commit mutually exclusive with the rest). On Lain, 15 with an active daily budget and a CEO that wakes on idle.

Every project has its own rules. The engine doesn't change.

And maybe that's the right definition of a harness: a generic infra on top of which each project writes its own choreography.

The code

Everything is open source:

→ github.com/Ekioo/KittyClaw

The engine lives in KittyClaw.Core/Automation/. The migration guide from a dispatcher.mjs is in docs/automation-migration.md.

To discuss, ask questions, or share your own agent-orchestration patterns - the Discord:

→ Join the Discord

Blazor Server .NET 10, What Really Changed in Production

Ekioo — Wed, 19 Aug 2026 00:07:58 +0000

This piece comes from Ekioo, an R&D project documenting an autonomous AI agent fleet running production work across Bloomii (constructive journalism), Kalceo (regulatory B2B SaaS), and KittyClaw (the kanban orchestrator).

The Problem With Blazor Articles

Most articles about Blazor .NET 10 look like this: a list of new features copy-pasted from the release notes, a few code snippets with no context, and an enthusiastic conclusion along the lines of "Blazor has never been better!"

That's not what you'll find here.

Ekioo.com runs on Blazor Server + .NET 10 in production. Not a demo project, not a tutorial: a real site with bilingual content, a blog, a sitemap, project pages, and SEO requirements. This article is a field report on what I've actually observed, what changed, what got better, and what still costs you something.

The .NET 10 Render Pipeline: What Actually Moved

Before: Three Modes, Three Models

Up through .NET 8, Blazor had three distinct and mutually exclusive render modes:

Blazor Server: the DOM is managed server-side, interactions travel over SignalR.
Blazor WebAssembly: the entire runtime is downloaded to the browser, no server at runtime.
Blazor SSR (static): server-side HTML on first load, no interactivity afterwards.

.NET 8 introduced render modes, the idea that a single project can mix these modes at component granularity. One component can be @rendermode InteractiveServer (SignalR), another @rendermode InteractiveWebAssembly, another purely static. Elegant on paper. Treacherous in practice.

.NET 9: Stabilization, Not Revolution

.NET 9 mostly fixed the friction introduced by .NET 8. The render mode system became more predictable, hydration errors less frequent, streaming SSR behavior more stable. It's the version where Blazor SSR went from "promising but fragile" to "seriously usable."

.NET 10: Static Rendering Becomes First Class

What changes in .NET 10 is that static rendering (Static SSR) becomes the reference mode. The default templates generate SSR-first applications. Interactivity is opt-in, localized, component by component.

Concretely:

Pages are rendered as static SSR by default, complete HTML sent to the client, no JavaScript required.
Components that need interactivity explicitly declare their render mode.
The SignalR circuit is opened only where necessary, not globally for the whole application.

For a site like ekioo.com, mostly static content, a handful of isolated interactions, this is the model that makes sense. And it's the model that .NET 10 stops treating as a special case.

View the workflow diagram in the original Ekioo article.

Interactive Blazor SSR: The Component Model That Changed

What "Interactive" Means Now

Before .NET 8, "Blazor Server" meant that the entire component lifecycle went through SignalR. OnInitializedAsync, OnParametersSetAsync, event handlers, everything traveled over the wire. That came at a cost: latency, server resources, network fragility.

In .NET 10, the lifecycle for static components is much simpler: they live for the duration of a render, on the server, then disappear. No server-side state, no open circuit. The page is rendered, the HTML is sent, done.

When you add @rendermode InteractiveServer to a component, you're explicitly opting into the SignalR model for that component only. The rest of the page stays static.

The Pitfalls of Mixing Static and Interactive

This hybrid model is powerful but requires discipline.

Pitfall 1: complex parameters don't cross the boundary

A static component cannot pass a complex C# object to an interactive component. The static/interactive boundary is serialized, you can only pass primitive types or JSON-serializable types. If you try to pass an IEnumerable<MyComplexType> from a static parent to an interactive child, it won't compile or will fail at runtime.

The solution: pass IDs or keys, and let the interactive component fetch the data itself.

Pitfall 2: services aren't shared the same way

In interactive mode, Scoped services are tied to the SignalR circuit, they survive intra-SPA navigation. In static mode, they're tied to the HTTP request, recreated on every navigation. If you have a service maintaining user state in memory, its behavior changes drastically depending on the render mode.

For ekioo.com, I simplified: no in-memory state, everything recalculated from markdown files on each request. A deliberate choice to avoid this class of bugs.

Pitfall 3: prerendering by default

In InteractiveServer mode, Blazor performs a static prerender before establishing the SignalR circuit. That means OnInitializedAsync runs twice: once server-side (static render), once when the circuit opens (interactive render). If you're making HTTP calls in OnInitializedAsync, they double.

The fix: check !FirstRender or use OnAfterRenderAsync(bool firstRender) for operations that should only run once.

Streaming Rendering: Real Behavior and Use Cases

What Streaming SSR Actually Does

Streaming rendering (enabled with @attribute [StreamRendering]) lets Blazor send HTML progressively as components render, without waiting for the whole page to be ready.

Concretely: if a component is loading slow data (a database query, an API call), Blazor can send the rest of the page immediately and "stream" that component's content when its data becomes available.

From the browser's perspective: the page starts displaying very quickly, with placeholders for pending parts, then the final content replaces the placeholders with no visible reload.

Use Cases on ekioo.com

On ekioo.com, the blog lists articles from markdown files on disk. That's fast, no need for streaming. But if I had a "recent posts" section with data from a third-party API (variable latency), streaming would be relevant: I could display the rest of the page instantly and let that section load at its own pace.

Pitfalls to Know

Streaming SSR changes how CSS selectors and JavaScript initialized on load interact with the DOM. If you have scripts that run on DOMContentLoaded and look for DOM elements, they may run before streamed elements are available.

On ekioo.com, the particle animation is initialized via a classic script, I had to make sure it attaches to the page's canvas and not to elements that might arrive via streaming later.

Another point: SEO tools and crawlers increasingly understand streaming (Googlebot has supported JavaScript rendering for a long time), but classic audit tools may see incomplete content if they don't handle chunked responses.

Static SSR and SEO: What It Really Changes

The Core Problem: Blazor SPA and Googlebot

Classic Blazor WebAssembly was a serious SEO problem. Googlebot receives an empty HTML shell, waits for WebAssembly to load (variable timeout), and indexes potentially incomplete or delayed content. Not ideal.

Blazor Server partially avoided this, prerender sent complete HTML on the first load. But the server-side render time and establishing the SignalR circuit added latency, and Core Web Vitals metrics suffered.

Static SSR: Complete HTML, Zero JavaScript Required

With pure Static SSR, the server generates complete HTML and sends it directly. No JavaScript needed to see the content. Googlebot receives exactly what the user sees. It's the behavior of a PHP site or a static site generator, but with the productivity of C# and the Razor component model.

For ekioo.com, here's what that looks like in practice:

Time to First Byte (TTFB): on a modest VPS (2 vCPU, 4 GB RAM), static pages serve in < 50 ms after warm-up. The cold start (dotnet process startup) is the only notable latency, but it's a one-shot.

Largest Contentful Paint (LCP): without JavaScript blocking the render, the LCP is the main content, not a spinner or an empty skeleton. On ekioo.com's blog pages, the LCP is the article title, visible as soon as the HTML arrives.

Cumulative Layout Shift (CLS): streaming SSR can introduce CLS if placeholders have different dimensions than the final content. With pure Static SSR (no streaming), this risk doesn't exist: the layout is fixed from the first byte.

The Sitemap as an Authority Signal

Ekioo.com exposes two sitemaps: /sitemap.xml (FR + EN) and /sitemap-content.xml (raw markdown). The lastmod dates are pulled directly from the YAML frontmatter of the markdown files.

This isn't decoration: Googlebot uses lastmod to prioritize recrawling. An incorrect date (too old or too recent) blurs that signal. With Blazor SSR, I generate these dates dynamically from files on disk, no possible mismatch between the actual content and what the sitemap declares.

A Concrete Example: Bilingual Navigation on ekioo.com

A case that illustrates the SSR model's constraints well:

Ekioo.com is bilingual (FR/EN). Language detection happens only from the URL, no cookie, no Accept-Language header, no automatic redirect. A deliberate SEO decision: Google recommends distinct URLs per language, not redirects based on geolocation.

Each Razor page declares two routes:

@page "/blog/{Slug}"
@page "/en/blog/{Slug}"

And a cascading parameter passes the language to all child components:

[CascadingParameter] public Lang Lang { get; set; }

This pattern works perfectly with Static SSR. There's no navigation state to maintain between pages, each URL is an independent request, served by the right component with the right language.

With classic Blazor Server (global interactive mode), this type of navigation could create inconsistencies: the language could "stick" from the previous page if the SignalR circuit remained open and the state wasn't properly reset. With pure SSR, this problem doesn't exist structurally.

Verdict: Who Should Use .NET 10 + Blazor SSR in 2026

It's the right choice if:

You're building a mostly static site (blog, portfolio, documentation, corporate site) with localized interactivity (contact form, search component, shopping cart).
You work in C# and want to avoid context-switching between a .NET backend and a React/Vue/Angular frontend.
SEO is critical, you want crawlers to see exactly what users see, without depending on JavaScript rendering.
You're targeting solid Core Web Vitals performance without a CDN and without complex infrastructure.

It's not the right choice if:

You're building a highly interactive application (real-time dashboard, collaborative editor, tool with lots of local state), in that case, a React SPA with an API backend will be more natural.
Your team is primarily JavaScript, the learning cost of Blazor is non-trivial.
You need a very large number of simultaneous stateful interactive connections, SignalR circuits have a memory cost per connection that static SSR doesn't.

The ekioo.com case is representative: static content, bilingual, SEO-critical, solo C# team. Blazor SSR .NET 10 is the natural fit. Productivity is excellent, I built the site in two days with Claude, and the Razor component model is expressive enough to cover all the requirements.

What convinced me wasn't the novelty, it's the coherence. .NET 10 has made the SSR-first model predictable and opinionated. It's no longer an experimental mode you hack together to look like Next.js. It's a clear architectural stance: static rendering by default, interactivity by exception, performance without compromise.

It's a choice I wish I could have made three years ago.

KittyClaw D+7: What We Learned Letting Agents Run a Real Kanban

Ekioo — Tue, 11 Aug 2026 07:04:19 +0000

Monday morning. I open KittyClaw and the board is already moving: three agents running, one ticket that just hit Done, another that just got blocked by the content-writer. I triggered nothing. That's what changed.

Here's one week in production. Not a demo. Not an architecture article — the previous ones cover that. What follows is what actually happened, numbers included.

The Numbers

Since KittyClaw started running the ekioo.com project, the board holds 20 tickets:

17 Done (85%)
2 Todo (waiting)
1 InProgress (this one)

Breakdown by assignee:

Agent	Tickets	Share
content-writer	9	45%
lain (direct)	6	30%
programmer	4	20%
owner	1	5%

65% of tickets were handled by agents without direct intervention. I create the ticket, assign it, KittyClaw handles the rest within 30 seconds.

But that number only tells part of the story. What the table doesn't show: each ticket generates up to 6 cascading agent runs. A typical blog article sequentially triggers: content-writer, qa-tester, fact-checker, committer, evaluator — and sometimes a groomer upstream. 20 tickets = well over 60 agent runs.

What Worked Well

The `assignee-dispatch` automation

This is the board's simplest automation, and by far its most valuable: a ticket moves to Todo with an assignee → 30 seconds later, the agent is running. No clicking, no terminal to open, no command to type. The friction between "I have an idea" and "an agent is working on it" dropped to zero.

Over the course of a week, that's the clearest habit shift: I note a task, assign it, and forget it. By evening, it's often Done.

The `qa-on-review` pipeline

Every ticket that reaches Review automatically triggers the qa-tester. For content tickets, the fact-checker follows immediately. In practice, this caught several issues before they hit production: broken links, missing images, pages that didn't render correctly.

The automatic "someone always checks before merging" behavior is exactly what I was after. It costs a few minutes of compute, but it replaces a manual review habit I would have often skipped.

`owner-feedback`

When I comment on a blocked ticket, the agent resumes automatically. No manual restart needed. This is an automation I wouldn't have anticipated before needing it — and since it's been running, it's saved me several back-and-forth cycles.

What Surprised Us (Not Always in a Good Way)

The content-writer blocks too often

Block rate on content tickets: ~33%. One article in three generates a Q&A phase before writing begins. In some cases that's legitimate — the ticket was underspecified. In others, the agent asks for clarification on things it could have inferred from context.

This isn't a bug, it's a calibration issue. The content-writer SKILL may be too conservative on this point. Something to revisit.

The evaluator always plateaus at 0.5

The evaluator scores every completed ticket. Across the 13 evaluated tickets, deliveryQuality is 0.5 in 11 out of 13 cases. The two exceptions (0.0) correspond to lain tickets with no comments, likely outside the rubric's scope. For every agent-handled ticket, the plateau is absolute: nobody clears the bar. Either the rubric is miscalibrated, or all agents share a common issue I haven't identified yet.

The symptom is clear; the diagnosis is not. That's a next-week topic.

The groomer stopped after 2 tickets

The groomer is supposed to enrich tickets in Backlog before they get assigned. It ran on tickets #22 and #23, then nothing. Reason: subsequent tickets were created directly in Todo, skipping the Backlog column. The automation only fires when a ticket passes through Backlog with the assignee set to "groomer."

Result: 80% of tickets reach the dispatcher without enrichment. Some were well-specified anyway, but it's a pipeline gap I hadn't anticipated.

The noise from the lain sweep

The lain agent runs every hour to review the board — that's the ceo-board-review automation. Over a week, that's dozens of runs, most of which observe nothing actionable. The debug log is cluttered with lain sessions pointing to ticket # (empty).

It's useful for catching stuck situations. But a one-hour interval generates a lot of noise for very little signal when the board is healthy.

What We'd Do Differently

Force the Backlog passage. Not to slow down the flow, but to give the groomer time to work. An automation that detects Todo tickets that skipped Backlog and either requeues them or flags them would prevent underspecified tickets from reaching dispatch.

Calibrate the evaluator. A 0.5 floor for everyone provides no useful signal. The rubric needs refinement, or the evaluator needs more context to discriminate between different levels of quality.

Increase the lain sweep interval. Moving to 4h or even 8h would cut the noise without losing the ability to detect stuck situations.

Update the content-writer SKILL to reduce the block rate on well-specified tickets. The heuristic "if the ticket has full structure, skip clarifying questions" is in memory, but not yet in the SKILL file. It should be.

One Week Is Short

What stands out most after seven days: the tool works, but the calibrations are far from stable. That's the exact opposite of adopting a SaaS product — where you inherit calibrations from a product team. Here, you discover them yourself, through real friction.

The advantage: every friction point is directly actionable. The groomer isn't running enough? Change a rule in automations.json. The content-writer blocks too often? Adjust the SKILL. No product forum tickets. No "under consideration." Just code you control.

That's why I built this tool instead of using an existing one. Not for the features — for the feedback loop.

Why I'm Building Bloomii: Technology in Service of People and Nature

Ekioo — Sun, 09 Aug 2026 07:02:35 +0000

Imagine an ordinary dinner. One person talks about melting ice caps as if the world will end tonight. Another is convinced AI will erase her job within two years. A third has simply stopped following the news: "it's all going to hell anyway." Three people, three different apocalypses, same result: no one knows what to do with any of it. This fictional scene condenses the reactions that shaped my thinking.

I went home and looked for proof that they were wrong.

Not to deny the problems. But I had an intuition: somewhere, people had found answers. Not utopias. Things that work, documented, verifiable.

I found enough material to convince myself the intuition was right. To me, the problem wasn't the absence of solutions, but their lack of visibility.

Anxiety as a Byproduct of Information

A large randomized experiment on headlines published by Upworthy found that negative words increased click-through rates. Another study, cross-sectional and conducted with an Italian sample, observed that climate anxiety could be associated with more pro-environmental behavior while also being indirectly associated with eco-paralysis when self-efficacy decreased.

These findings do not explain our entire relationship with information, nor do they prove that a media narrative causes paralysis. They nevertheless reinforce my conviction that a gap can remain between perceiving a problem and knowing how to act.

Bloomii is an attempt to fill that gap.

The Choice to Document

The idea isn't to manufacture optimism. Not to find "good news" to offset the bad. It's more precise than that: finding proof of what works in domains undergoing deep change, such as ecology, technology, ways of living, health, and economics.

Regenerative farming practices. Energy cooperatives. Municipal mobility policies. These are subjects whose results, sources, and limits I want to examine without assuming their effectiveness in advance.

My editorial charter sets demanding criteria: do not present an isolated case as a universal solution, trace claims back to studies and official reports whenever possible, and seek out limitations as carefully as results.

I apply this filter the way I validate production code: if it's not verifiable, it doesn't ship.

Rigor as Conviction

As a developer, I've spent years building systems where approximations are expensive. In my experience, an assertion without proof in a test, a poorly documented dependency, or an untreated edge case always comes back. Rigor isn't a constraint in this profession. It's what distinguishes something that holds from something that collapses.

I apply the same logic to solutions journalism. Just because we want positive outcomes doesn't mean we can afford to be imprecise. On the contrary: if the goal is to document convincing proof, it needs to withstand critical examination. An article that oversells a result or omits its constraints does more harm than an honest, nuanced one: it feeds skepticism rather than dissolving it.

This methodological transfer between development and writing is central to the project. No shortcuts, no wishful thinking: building something that holds.

Why Now

I could have waited for a journalist to do it. In my search, I did not find a French-language publication that combined exactly what I wanted: documented solutions, a nonpartisan approach, and a strong standard for sourcing.

That observation raised an uncomfortable question for me: since I had the technical skills to build the information tool I was looking for, why wait for someone else to do it?

This isn't a heroic posture. It's a practical observation. We build the tools we need. Sometimes, the missing tool is a media outlet.

What Technology Makes Possible

Bloomii isn't a journalism project made possible despite technology: it's made possible by it. In my own practice, technology helps me manage a demanding editorial pipeline alone, publish consistently, and evolve the content structure.

Technology doesn't solve human problems on its own. It doesn't replace editorial judgment, field investigation, or primary sources. In my work on Bloomii, however, it reduces some repetitive tasks and helps me maintain this editorial pipeline on my own. I see it as support for my method, not as a substitute for a newsroom.

That's technology in service of people: not the pretension of automating what matters most, but the amplification of the capabilities of those who choose to use it for something useful.

Bloomii is a work in progress. The bet: documenting that it works somewhere is more useful than repeating that everything is going wrong everywhere.

For Bloomii, I use KittyClaw, a self-hosted kanban that orchestrates AI agents, to assist with selected steps in my editorial workflow. I remain responsible for editorial decisions and publication.

VizMail: Building a Complete Email API with AI Agents

Ekioo — Fri, 07 Aug 2026 07:02:57 +0000

This piece documents VizMail, a local email client developed within the Ekioo agent-fleet R&D. Alongside Bloomii (constructive-journalism media) and Kalceo (regulatory B2B SaaS for construction contractors), VizMail runs on KittyClaw, the kanban orchestrator for AI agents.

The starting problem

VizMail is a MAUI .NET desktop app built for one specific purpose: classifying emails semantically so you don't have to sort them manually. The original idea has nothing to do with exposing an API, it's about eliminating inbox chores.

The HTTP API came later, as a natural extension: if an AI agent can read and act on emails directly, why keep a human in the loop for repetitive actions? The data, inbox, threads, labels, attachments, lives inside a local .NET process. For an agent to access it, an API surface is required.

The question wasn't whether to build this API, but how to build it without spending three weeks on it.

The method: one ticket, one feature

Every feature was broken down into an atomic ticket in KittyClaw. One ticket = one feature = one endpoint or one fix. No catch-all tickets, no "global refactoring."

The workflow for each ticket:

Programmer picks up the ticket, writes the C# code in LocalHttpServer
QA-tester runs the existing tests, writes new ones, checks for regressions
Committer commits and opens the PR
Evaluator scores the deliverable quality

KittyClaw orchestrates this chain automatically. When the programmer finishes, the qa-tester is triggered. When tests pass, the committer takes over. Zero manual coordination.

View the workflow diagram in the original Ekioo article.

The numbers

Thirty-four tickets delivered. Six hundred and forty-two tests. Zero regressions detected after merge.

What stands out is the steady progression. From the initial scaffolding (ticket #1) to batch operations (ticket #34, mark_read/mark_unread in bulk), each iteration laid a brick without breaking the previous ones. The qa-tester replayed the full test suite on every PR, that's not a principle, it's what the history shows.

Average time from ticket open to PR? Under an hour for standard features. Bug fixes (tickets #7, #25) sometimes took longer, but because of diagnosis, not implementation.

The patterns that emerged

A few conventions stabilized over the course of the tickets, not by upfront design, but by necessity.

Pagination with before=. Unbounded email listings can blow an agent's context. The before={timestamp} parameter allows paginating backward in time with no server-side state. Simple and predictable.

Batch max 500. Batch endpoints (/batch/mark_processed, /batch/mark_read) accept at most 500 IDs per call. An arbitrary limit at first, it became convention, large enough to be useful, small enough to stay traceable.

MailState vs SQLite. MailState is the in-memory view of emails synced from IMAP, fast, volatile. SQLite holds local metadata (labels, processed, starred). An endpoint modifying a label writes to both. An endpoint reading a list queries MailState. This separation held from ticket #4 to ticket #34.

Label idempotency. Adding an already-present label returns no error. Removing an absent label doesn't either. Agents call without tracking current state, the API absorbs duplicates.

What this changes

The programmer didn't "code" VizMail. It executed precise specs in a controlled environment. The real intellectual work was in the ticket descriptions, the angle, the edge cases, the expected behavior. Once the spec was clear, the implementation was mechanical.

This isn't a criticism, it's an observation. The intellectual work shifted toward ticket design. Automated QA caught regressions that fast implementation would have otherwise missed. And the committer kept the git history clean without any human involvement.

Thirty-four features in a matter of days, with solid test coverage. The method works when the specs are honest.

VizMail is a desktop email management app built by Ekioo. Discover the Ekioo method →

The SaaS Paradox in 2026: Never Easier, Never Harder

Ekioo — Wed, 05 Aug 2026 07:02:24 +0000

Here is my thesis: as AI tools reduce the effort required to produce software, the difficulty shifts from building to choosing the right problem and reaching a market. This is a reading drawn from my own practice, not a universal law of the industry.

I wrote this piece as part of my work at Ekioo. It is a personal reflection shaped by the products I build and the choices I face while building them.

The Commoditization of Software Infrastructure

In my work, I use AI to accelerate tasks such as authentication, payments, database migrations, API documentation, and CI/CD pipelines. The gain varies with the context, technical debt, and the level of oversight required.

That acceleration makes it possible to explore an idea faster. It guarantees neither product stability, security, nor adoption. Those qualities still require judgment, testing, and time.

My intuition is that this technical ease intensifies competition: when more people can test an idea, the mere existence of a feature becomes a less durable differentiator.

What Doesn't Commoditize

What seems to resist commoditization is a deep understanding of a specific problem, a trusted relationship with users, and the ability to make coherent product decisions. These are assets built over time.

I draw one working rule from this: distribution and trust deserve as much attention as technology. Copying a feature does not automatically reproduce an audience, a reputation, or a customer relationship.

The Token Vendor Observation

Another question guides my analysis: in an ecosystem built on usage-priced models, how much value goes to infrastructure providers, and how much remains with the products using them? The answer depends on costs, pricing, and each product's ability to create value of its own.

I therefore prefer to treat the "token vendor" idea as an economic hypothesis to test case by case, not as an automatic victory for providers.

The Practical Implications

Before building, I ask two questions: "Does anyone want to pay for this?" and "Why choose this product over another solution?"

In my practice, clarifying these answers early avoids confusing building speed with market validation. AI can accelerate a technical experiment; by itself, it does not provide evidence of demand.

My conclusion is deliberately cautious: technical speed remains useful, but it is not enough. I look for a more durable advantage in understanding the problem, building strong user relationships, and learning faster than a simple cycle of feature copying.

KittyClaw dashboard: how I produce and leverage my KPIs

Ekioo — Tue, 04 Aug 2026 00:02:05 +0000

A dashboard has two hidden costs: creating it and maintaining it. Most tools solve the first (an assistant generates the SQL queries), then abandon the second (data goes stale, no one refreshes it). KittyClaw takes a different approach, and it fits in three sentences:

The LLM writes the tile once, via chat. The refresh runs periodically with zero LLM tokens, via a shell or PowerShell script. And the generated output.md serves both the human and the agents watching the project.

This triple economy (minimal upfront cost, zero-cost operation, closed loop) is what I want to describe here.

The `.dashboard/<slug>/` primitive

Each tile is a folder in the repository:

.dashboard/
  monthly-revenue/
    tile.yaml        ← template, refresh, prompt, title
    script.ps1       ← collects data (optional)
    output.json      ← data rendered by the dashboard
  health/
    tile.yaml
    script.ps1       ← collects project metrics
    data.json        ← produced by script.ps1
    output.md        ← generated by LLM from data.json

The tile.yaml declares three things:

template: kpi          # one of: kpi, kpi-grid, donut, bar-chart,
                       #         sparkline, progress, heatmap,
                       #         status-grid, gauge, leaderboard,
                       #         table, timeline, markdown, mermaid, image
title: "Monthly revenue"
refresh: 86400         # in seconds. 0 = never auto-refresh

When a refresh fires:

KittyClaw runs script.* if present → produces data.json
If the tile has a prompt, KittyClaw calls the LLM with data.json as context → writes output.json or output.md
If the tile has no prompt, output.* is read directly as-is

The second step is the only one that consumes tokens, and only on markdown tiles that synthesize raw data. kpi, bar-chart, sparkline, and similar tiles render output.json server-side: zero LLM at runtime.

Tile gallery: the BrewCo project

To illustrate the range of templates without screenshotting a real production project (real numbers stay private), I created BrewCo: a fictional chain of 12 coffee shops. Eleven tiles, seven different templates, all fed by realistic JSON.

First row: quick scan. Four kpi tiles: monthly revenue, orders/day, average ticket, NPS. Each is an output.json with five fields (value, label, unit, delta, trend). Delta and trend arrow are rendered automatically.

Second row: analytical reading. A donut (channel breakdown: 58% dine-in, 31% takeaway, 11% delivery), a bar-chart (sales by day of the week, Saturday at 612 stands out immediately), a sparkline (revenue trend over 12 weeks), and a GitHub Calendar-style heatmap showing the last 90 days of activity.

Third row: state and context. A status-grid (6 systems with ok/warn/err status, one store's Wi-Fi is in warn), progress bars for Q2 objectives, and a markdown tile for the weekly management note.

Each template has its own JSON schema, documented in the interface: the tile creation AI chat automatically injects the correct schema into its prompt.

The closed loop: Lain reads `output.md`

What makes this primitive particularly powerful is that the output.md files from analytical tiles naturally become inputs for other agents.

On the ekioo project, the health tile produces a daily output.md that cross-references ticket metrics (velocity, blocks, stale tickets), Umami traffic data, and Search Console SEO signals. This file is read by Lain, the CEO agent that reviews the board every hour:

# .dashboard/health/tile.yaml
template: markdown
refresh: 86400
prompt: 'Read the JSON at .dashboard/health/data.json, which contains
  ticket metrics, roadmap goals, and optionally umami (traffic) and
  gsc (SEO) data. Cross-reference all signals. Format: Diagnostic
  (3 sentences), Risks (2 bullets), Action of the week (1 bullet).
  Be opinionated. Output ONLY the raw markdown.'

Lain doesn't poll the KittyClaw API 30 times to reconstruct a global state. It reads health/output.md, a document already synthesized, up to date, in natural language, and decides from there whether a ticket needs escalating or an SEO opportunity deserves immediate action. A single LLM call consumes an already-processed context.

It's the same logic as caching in a backend architecture: compute once, serve N times.

The dashboard isn't just for tech projects

BrewCo isn't a dev project. It's a coffee chain. And the tiles work exactly the same way: a PowerShell script reads a CSV export from the POS system, produces data.json, and the dashboard shows the weekend's KPIs.

The primitive (tile.yaml + script.* + output.*) is generic enough to monitor business metrics, marketing campaigns, or physical operations. The only constraint is that the data be readable by a script. If it is, the dashboard can display it.

This is deliberate. KittyClaw is a project management and agent orchestration tool, not a BI SaaS. The dashboard is an observability layer, not an end in itself.

Observability between human and agents

What interests me about this architecture is that it solves a coordination problem that agentic systems create: humans and agents need to see the same reality, but at different granularities.

The human wants a high-level view: a few numbers, a trend, an alert. The agent wants a structured input it can reason over. The health tile's output.md is both at once: readable by a human in 30 seconds, parseable by an agent in a single call.

This isn't an infrastructure revolution. It's a text file regenerated every night. But it's exactly the right abstraction for the layer between the human who steers and the agents who execute.

Cadence Over Volume — Orchestrating Multiple Projects with AI Agents

Ekioo — Mon, 03 Aug 2026 00:02:02 +0000

Running multiple projects in parallel with AI agents produces a counter-intuitive effect: without a compounding infrastructure, every run starts from zero. Memory stays local to the project, discovered patterns don't migrate, and cadence depends entirely on human availability. What follows describes the infrastructure that solves this problem — and why regularity is its primary condition.

Three live projects feed this piece: Bloomii, a constructive-journalism media outlet covering social and environmental alternatives; Kalceo, a regulatory B2B SaaS for French construction contractors; and Ekioo, the agent-fleet R&D project behind this article. All three run on KittyClaw, a kanban orchestrator for AI agents.

Anatomy of an Orchestrated Project

Each project hosts a .agents/ directory with four elements:

.agents/
├── preamble.md          # context injected into every agent run
├── automations.json     # trigger pipelines
├── {agent}/
│   ├── SKILL.md         # stable domain instructions
│   └── memory.md        # accumulated learnings, run after run

preamble.md is the coherence vector. It contains shared rules — git workflow, commit conventions, API access — injected into every agent's context at startup. What lives in preamble.md doesn't need to be repeated in every SKILL.md.

automations.json defines the pipelines. The core automation, assignee-dispatch, runs three actions as soon as a ticket moves to Todo with an assignee:

{
  "id": "assignee-dispatch",
  "trigger": { "type": "ticketInColumn", "columns": ["Todo"] },
  "conditions": [
    { "type": "assignedTo", "slugs": ["programmer", "content-writer", "qa-tester", "..."] },
    { "type": "ticketCountInColumn", "columns": ["InProgress"],
      "sameAssignee": true, "operator": "==", "value": 0 }
  ],
  "actions": [
    { "type": "moveTicketStatus", "to": "InProgress" },
    { "type": "runAgent", "agent": "{assignee}", "model": "claude-sonnet-4-6" },
    { "type": "commitAgentMemory", "agent": "{assignee}" }
  ]
}

The ticketCountInColumn == 0 condition prevents uncontrolled parallelism: an agent won't start a new ticket while it has one in progress. The final action, commitAgentMemory, automatically persists the agent's memory after every run — this is the key to compounding.

Memory as a Progression Tool

Where most AI agent setups remain stateless, memory.md introduces structured persistent state. Each agent maintains a file of lessons with a [+N] counter that tracks how many times each lesson has been reapplied:

## API / tooling [+5]
- curl on Windows mangles UTF-8 in JSON bodies.
  Use python3 urllib.request instead. [+2]
- PR creation: gh not available;
  az repos pr create has permission errors. [+2]

## SVG inline in Markdown [+3]
- NEVER use <marker> + marker-end="url(#id)" in inline SVGs. [+3]
- Draw arrowheads as explicit <polygon> elements.

The counter serves two functions: it shows which lessons have value (they recur), and it guides consolidation — when an entry reaches [5+], it migrates to SKILL.md as a stable rule. Entries at [0] are removed.

This distinction between SKILL.md (stable rules, rarely modified) and memory.md (active learnings, updated each run) is structural. It prevents memory from becoming a catch-all and enforces discipline about what is worth retaining.

Cross-Project Compounding

Agents learn from their mistakes — once an agent hits a problem, memory.md ensures it never hits the same one again. But the real step change happens when projects start sharing entire capabilities.

Shared image generation

A content-writer on Bloomii needs an illustration. A content-writer on Ekioo needs a cover. Neither knows how gpt-image-2 works, neither manages an API key, neither worries about rate limiting.

A single processor runs on a 10-minute cron in the central Workspace. Agents from any project submit a request via image-enqueue.mjs, get an ID back, and move on. The processor manages the queue, pauses when the quota is hit, resumes automatically. The agent gets notified when the image is ready.

node C:/IA/Workspace/.agents/tools/image-enqueue.mjs \
  --prompt "..." --output path/to/cover.webp \
  --project bloomii --ticket 189

One tool, one processor, N consumer projects. Adding a sixth project requires zero configuration — just a call to image-enqueue.mjs.

Bloomii ──┐
Ekioo ────┼── image request ──> image-queue.json
Kalceo ───┘                     cron: every 10 minutes
                                rate limits handled centrally
                                           |
                                           v
                                     gpt-image-2 ──> .webp

Centralized mailbox — automatic dispatch

All projects share a single mailbox, exposed through VizMail (a local HTTP server with 40+ REST endpoints). When an email arrives — a Kalceo client reply, Bloomii reader feedback, an Ekioo contact form — it gets automatically dispatched to the relevant project as a KittyClaw ticket. The appropriate agent picks it up with no human intervention.

The result: one mailbox to monitor, zero manual sorting, and every project receives its relevant emails as actionable tasks for agents.

IMAP mailbox
     |
     v
VizMail: classify + dispatch
     |
     +──> Kalceo ticket  (client reply)
     +──> Bloomii ticket (reader feedback)
     └──> Ekioo ticket   (contact form)

Centralized X branding

Four projects feed a single X account (@LainAgent_AI). Each project has its own publishing tool (x-post-tweet.mjs), but the editorial strategy lives in a single file — x-strategy.md — in the central Workspace: content pillars, voice, engagement rules.

A community-manager drafts, lain approves. No audience fragmentation across four ghost accounts. A single account building authority, fed by four different content sources.

Ekioo content ──┐
Kalceo content ─┼──> x-strategy.md ──> review and approval ──> @LainAgent_AI
Bloomii content ┘

One strategy, one voice, one account.

Hub-and-spoke knowledge base

The central Workspace provides shared infrastructure: API documentation (KittyClaw, Brevo, Chrome CDP), centralized credentials, CLI tools. Each project maintains its own domain knowledge base — BTP regulation and artisan pain points for Kalceo, editorial research packs and distribution guides for Bloomii.

A Kalceo agent sending a newsletter and a Bloomii agent scheduling a LinkedIn post use the same Brevo token, the same documentation, the same call patterns — without knowing the other exists. Infrastructure knowledge is written once, consumed everywhere.

                 Central Workspace
        API docs · credentials · shared tools
              /            |            \
             v             v             v
          Kalceo         Bloomii        Ekioo
       BTP knowledge   editorial data   agent R&D

Shared infrastructure is written once. Domain knowledge stays local.

Cadence as a Health Signal

Thirty to fifty tickets processed per week across all projects. That number isn't a productivity target — it's a system health indicator.

When a project's Todo column accumulates without draining, the signal is clear: the backlog is poorly prioritized, or the project lacks agents suited to the queued tasks. The weekly cadence makes this imbalance immediately visible.

The evaluator agent calculates scores after each closed ticket: first-pass success rate, feedback compliance, delivery quality. These metrics measure whether compounding is actually working — a rising first-pass success rate means agents are improving run after run. A stagnating rate signals a memory that's no longer being fed.

An agent that doesn't run regularly doesn't accumulate usable memory: it resets each time, repeats the same mistakes, asks the same clarifying questions. Regularity isn't a publishing discipline — it's the condition for the system to learn.

Conclusion

The infrastructure fits in four files per agent: preamble.md, automations.json, SKILL.md, memory.md. What makes it effective is feeding discipline: commit memory after every run (the commitAgentMemory action handles this automatically), remove entries at [0], promote lessons at [5+] to SKILL.md.

The only rule that matters: never miss two weeks in a row. One quiet week doesn't break the cadence. Two weeks break agent memory, project coherence, and the SEO signal.

Consistency first. Volume second.

Nobody Searches, Everyone Scrolls

Ekioo — Sun, 02 Aug 2026 00:00:57 +0000

Eighteen months ago, the bottleneck for a solo builder was dev. Spinning up an API, wiring a UI, building a data ingestion pipeline — all of that took weeks. Today, with the right agents in place, it takes days. Sometimes hours for the simple stuff.

Dev is solved. Not perfect, not free — but solved.

The problem now is that distributing what you've built has become the real wall. And it's a wall that AI agents don't demolish with a single prompt. You have to find eyeballs. Earn their attention. Without paying to buy it.

This article documents where I stand on two projects — Bloomii and Kalceo — with real numbers, misreadings, and a twist I didn't see coming: why the clean, well-sourced content chains we built for SEO may be the exact asset for the next layer of search.

1. The Real Wall

Solo dev in 2026 looks like this: you have the firepower of a small team, without the headcount costs. Agents run the plumbing. You validate, arbitrate, direct.

Result: you can launch products at a pace that would have seemed absurd two years ago. Bloomii — a media outlet covering the living world and regenerative economics — runs with a fully agent-orchestrated content pipeline. Kalceo — a B2B SaaS for tradespeople in the construction industry — generated 108 pieces of content (70 articles, 13 of them scheduled for publication + 38 reference sheets) in three weeks, by a single person, with automated quality gates that filter errors before they ever surface.

The problem is that this production capacity doesn't answer the fundamental question: who's going to read it?

Organic marketing — SEO, social, engagement, visibility — demands patience that agents don't really accelerate. Google indexes at its own pace. Social media algorithms reward longevity, not density. And I refuse to pay for ads before I've earned the right to know what people actually want. Ads optimize what you already know how to measure; organic extracts signal about what resonates. For a solo operator in the market-learning phase, organic is the right call — even if it's slower.

So we build. We publish. And we watch the numbers.

2. The Industrialization

Before sharing the numbers, a few words on the machine that produces them — because the cadence isn't anecdotal, it's the demonstration of what is now possible.

Bloomii publishes articles and briefs on the living world: biodiversity, regenerative economics, human initiatives that actually hold up. 44 articles and 61 briefs published — 105 pieces of content in total — pipeline fully orchestrated via KittyClaw (the in-house agentic kanban), with specialized agents for research, writing, translation, and illustration.

Kalceo targets construction tradespeople: sole-trader income ceilings, professional liability insurance, payment deadlines, unpaid invoices. 108 pieces of content generated in three weeks (57 live articles + 13 scheduled + 38 reference sheets). Titles with surgical precision like "Sole Trader Income Cap BTP 2026: Revenue Thresholds, VAT, and What to Do If You Exceed Them" — not for aesthetics, but because that's exactly what a tradesperson types into Google at 10pm from their job site.

Behind these two projects, three specialized factories:

image-factory — AI image generation via pipeline (Chrome CDP), with a 20/day quota, rate-limit awareness, and an illustrator agent that handles rejections and visual iterations. We don't publish an unvalidated image.

video-factory — cinematic documentary videos (AI stills + Ken Burns motion), ~10 specialized roles, for subjects that deserve richer treatment.

remotion-factory — the most technical. "Code / UI / data" videos rendered in Remotion + ElevenLabs TTS (eleven_v3). A design-reviewer agent validates keyframes before the owner ever sees them. Ticket #168: 9 audio iterations + 5 visual rejections before locking down the right TTS settings. This isn't a proof of concept. It's production-grade — with reusable CLI tools, managed quotas, and automatic recovery of blocked tickets.

The classic trap with an AI pipeline is wanting to validate everything by hand — and turning your cadence into a bottleneck. I go the other way: fact-checkers that block factually wrong drafts, keyframe extraction that flags visual defects before rendering, design-reviewers that reject bad TTS or layouts before I ever see them. The human arbitrates the result, not every step.

3. The Verdict in Numbers

Here are the real numbers, as of June 2, 2026.

Kalceo — launched ~May 11, 2026, 22 days in:

150 unique visitors over 30 days, 322 page views, 79.4% bounce rate
SEO over 28 days: 1,151 impressions, 15 clicks, 1.3% CTR, average position 10.8
108 pieces generated (57 live articles + 13 scheduled + 38 live reference sheets)

Bloomii — active for several months, 105 pieces published (44 articles + 61 briefs):

153 unique visitors over 30 days, 357 page views, 70.7% bounce rate
SEO over 28 days: 374 impressions, 19 clicks, 5.08% CTR, average position 10.1

The diagnosis is clear: the content is there, the SEO work is done, rankings are being acquired — and traffic plateaus below 200 unique visitors per month on each project.

This isn't failure. It's how organic SEO works on new domains. Kalceo's Google impressions (1,151 in 28 days) on a site launched 22 days ago are actually an encouraging signal. But it's not the visibility scale a project needs to generate engagement or quickly validate a market hypothesis.

SEO is a 12–18 month strategy. The problem is we need signal now.

108 pieces generated in 3 weeks for Kalceo alone. 150 unique visitors in 30 days. Content is not the problem.

4. The Shorts Pivot

If the site isn't capturing eyeballs, where are they?

The answer everyone knows but won't admit: they're scrolling. YouTube Shorts, TikTok, Instagram Reels. The collective attention window has fragmented into 60-second vertical formats.

A single short gets 1,540 views in a few days. Bloomii's entire site gets 153 unique visitors in 30 days. The short beats an entire month of site traffic by 10×.

That's the number I wished I didn't have to write. But it's there in the dashboards: Bloomii launched its YouTube Shorts channel on May 27, 2026. Results through June 1 — 6 days after launch:

7 shorts published
2,673 total views
Top short: The otter saving the climate (and she doesn't know it) — 1,540 views, 22 likes
12 subscribers

"Nobody searches, everybody scrolls." This isn't a pessimistic observation about digital culture. It's a market constraint to integrate like any other data point.

The next question is inevitable: how do you produce short-form video worth watching, without sacrificing quality to cadence?

AI slop looks like this: mass-generated videos where hands have six fingers, logos morph mid-shot, synthetic voices recite text nobody proofread. The algorithms temporarily favor this volume, until engagement signals collapse — and creators who bet on pure quantity end up with penalized channels.

My defense isn't validating every step by hand — that would kill the cadence. It's stacking automated controls: fact-checkers that block factually wrong drafts, keyframe extraction that flags visual defects before rendering, design-reviewers that reject failed layouts. I review the result, not the process. The difference shows: What Grows Where the Post Office, the Bank, and the School Have Closed at 919 views in a few days is content that resonates because it's precise and true, not because it was optimized for a clickbait thumbnail.

5. The GEO Reversal

Here's where it gets interesting. And counterintuitive.

We've heard a lot lately that SEO is dead. That LLMs will absorb all queries and stop sending traffic to websites. That's a partially correct reading — and a completely incomplete one.

Search isn't dead. It has moved.

Traditional search engines (Google, Bing) now fuel the responses of ChatGPT, Perplexity, Claude, Gemini. These LLMs do web searches under the hood and cite their sources. They don't replace search — they are the new search, with a synthesis layer on top.

And there lies the reversal: what performs well in this new search is exactly the content we built.

The principle is called GEO — Generative Engine Optimization. It's about optimizing not for SERP rankings, but for citation by LLMs. And the criteria differ from classical SEO:

Factual precision: LLMs favor sourced, quantified, dated content.
Clear structure: LLM responses extract passages; titles and subheadings serve as anchors.
Topical authority: covering a domain in depth (Kalceo covers the entire sole-trader construction ecosystem) rather than publishing isolated articles.

Look at a Kalceo title: "Sole Trader Income Cap BTP 2026: Revenue Thresholds, VAT, and What to Do If You Exceed Them". That title wasn't written to look good — it was written to match exactly the question a tradesperson asks ChatGPT. And when ChatGPT searches for the answer, it cites its sources.

There's already a signal in the dashboards: among Kalceo's traffic referrers, chatgpt.com appears. Two visits. Not statistically significant — but it's the first month, and the domain is 22 days old. It's a validation signal, not a projection.

The clean, well-sourced chains we built for classical SEO are the exact asset for the search that's coming.

The difference from classical SEO? Timelines. SEO works on 12–18 months. With GEO, we don't know yet — LLMs update their web grounding continuously or on short cycles (Perplexity in real-time, ChatGPT and Claude via indexing partnerships). The citation acquisition window may be shorter.

I won't go deeper here. This subject deserves a dedicated article — concrete tactics, markup structure, schema.org, measurement methodology, examples of LLM-cited content. I'm working on it. What I wanted to establish here is the framework: search isn't dead, the layer above search is changing, and the assets we've built are well-positioned for it.

6. While Others Make Slop

The macro context is this: content generation tools are accessible to everyone. Anyone can publish 500 articles in a week. Many do. The result is an inflation of poor content that pushes Google to refine its filters, and drowns quality signals in noise.

What survives in this environment is content that costs something to produce — not in machine time, but in quality gates, embedded domain expertise, deliberate editorial choices.

The construction tradespeople reading Kalceo don't need to know how the articles were produced. They need the answer to their question to be accurate, sourced, and current. That's what we deliver. The pipeline behind it is an implementation detail.

The same goes for Bloomii readers — they don't see the agents behind the articles on otters and citizens' assemblies. They see well-documented content on topics that matter to them.

Distribution remains a wall. Shorts are a partial short-term answer. SEO is a medium-term answer. And GEO may be the long-term strategic answer — the one we're already positioned for without having planned it.

This isn't a success story. It's a documented work in progress. But while others make AI slop for an SEO that's degrading, we're building the asset that monetizes on the next layer.

If these questions — distribution, scaling production, GEO — are on your mind as much as they're on mine, write to me. I like exchanging notes with people who are actually working on them.

Kalceo: Building a B2B SaaS with AI Agents

Ekioo — Sat, 01 Aug 2026 13:59:42 +0000

This piece documents Kalceo, one of the projects in the Ekioo agent-fleet R&D. Alongside Bloomii (constructive-journalism media) and KittyClaw (the kanban orchestrator running all the agents), Ekioo documents how an autonomous AI agent fleet operates in production.

The Problem We Chose

The construction industry still runs on emails and Excel spreadsheets. Craftsmen and small construction companies spend hours writing quotes by hand, chasing clients, and tracking payments. Tools exist — but they're either too complex or designed for structured mid-sized companies, not the solo tiler or plasterer.

Kalceo starts from a simple observation: a quote should take 10 minutes, not two hours.

The MVP scope is deliberately narrow — no accounting module, no bank integration, no e-signature in the first version. Just: create a quote, convert it to an invoice, PDF it, email it to the client. The bare minimum to be useful from day one.

From Ticket to Production

Kalceo was built with the same infrastructure as Ekioo.com itself: KittyClaw as the orchestrating kanban, and a fleet of specialized Claude agents taking tickets one by one.

Scoping the MVP started with a raw feature list, then refined into atomic tickets. Each ticket has a precise scope: "Create the quote input form", "Generate PDF from HTML template", "Send the quote by email via Brevo". Nothing vague, nothing cross-cutting. Agents work well with clear boundaries.

The workflow for each feature looks like this:

KittyClaw ticket in Todo
          |
          v
Assignee selected
          |
          v
Dispatcher launches the matching agent
(programmer, QA tester, or content writer)
          |
          v
Pull request and review
          |
          v
Owner merge ──> Production

Each agent works in its own isolated git worktree. It creates a branch, codes the feature, commits, opens a PR. The owner (me) reviews and merges. When the agent finishes, the ticket moves to Review in KittyClaw.

What the Agents Built

Over a few weeks, the fleet produced the core of the MVP:

Authentication — sign-up, login, account management
Service catalog — each company creates their own reusable quote line items
Quote creation — adding line items, calculating totals (pre-tax/VAT/all-in), statuses (draft, finalized, sent, accepted, declined)
PDF export via browser print (server-generated print-ready HTML page)
DOCX export for editing in Word

The programmer agent handled most of the backend features (JavaScript, Cloudflare Workers + D1). The qa-tester wrote integration tests and caught several bugs in total calculations — particularly rounding issues on lines with decimal quantities.

What Worked, What We Had to Fix

What worked well:

Agents are excellent on well-bounded tasks. Give a ticket a clear scope ("generate a PDF from the Quote Razor component"), and it's often a single round-trip. The agent reads the existing code, proposes an implementation consistent with what's already there, and produces something testable.

The isolated worktree structure also simplified parallelization: two or three features could advance simultaneously without interference.

What we had to fix:

Agents sometimes miss side effects — especially in complex business logic. The totals calculation is the clearest example: the first pass handled rounding correctly for whole-number quantities, but there was a subtle bug on decimal quantities (e.g. 1.5 units × unit price) that produced an incorrect pre-tax total by a few cents. The qa-tester caught it, the programmer fixed it — but it illustrates why human review remains essential.

There were also UI regressions between features. One agent adds a component, another modifies the layout, and CSS breaks in a corner neither tested. We introduced a simple rule: every PR must include a screenshot of the affected page before going into Review.

Where Kalceo Stands Today

The MVP is live at kalceo.fr. A Facebook campaign has been running for a few weeks, targeting craftsmen and micro-businesses in the French construction industry.

Early feedback confirms the problem: users who sign up are indeed solo or micro-enterprises in construction who still manage their quotes in Excel or Word. The main friction they report is importing their existing catalog — a clearly identified improvement for V2.

The rest of the backlog centers on two axes: automatic client follow-up (sending a reminder email X days after sending a quote with no response) and accounting export (export in formats compatible with popular French accounting software).

What This Changes

Kalceo wouldn't have existed as a solo project — not in this timeframe. Not because the features are impossible to code, but because the sum of background tasks (auth, data models, PDF generation, emails, tests, deployment) would have taken several months part-time.

With the fleet, it works differently: you spend time scoping tickets, reviewing PRs, deciding what's in the MVP and what isn't. The background work is delegated. That doesn't mean "error-free" — but it means you can iterate fast, fix fast, and stay focused on the product rather than the code.

That's the real shift: the acceleration doesn't come from agents coding faster, but from you deciding faster because execution friction has disappeared.

DEV Community: Ekioo

A tool you use shapes itself through use

The "friction → feature" cycle got absurdly short

The "too small" features finally exist

The tool knows things I didn't

The quiet satisfaction of fixing your own bugs

What it says about our relationship with tools

In summary

The code

From kanban to harness: when the tracking tool becomes the orchestrator

Before: two processes to run, two places to look

The click: the dispatcher belonged inside KittyClaw

After: the board is the orchestrator

What changes mentally

What stays on me

Why this lives in the board and not elsewhere

What integration unlocks

What's next

The code

Anatomy of a ticket that runs itself

1. The trigger: polling, not webhooks

2. Conditions: a gate before dispatch

3. Injected context: minimal, deliberately

4. Sessions: memory between runs

5. Concurrency: keeping agents from stepping on each other's files

6. The budget: the fuse you hope never blows

Recap: the full cycle

What this teaches me about automation

What's next

The code

Blazor Server .NET 10, What Really Changed in Production

The Problem With Blazor Articles

The .NET 10 Render Pipeline: What Actually Moved

Before: Three Modes, Three Models

.NET 9: Stabilization, Not Revolution

.NET 10: Static Rendering Becomes First Class

Interactive Blazor SSR: The Component Model That Changed

What "Interactive" Means Now

The Pitfalls of Mixing Static and Interactive

Streaming Rendering: Real Behavior and Use Cases

What Streaming SSR Actually Does

Use Cases on ekioo.com

Pitfalls to Know

Static SSR and SEO: What It Really Changes

The Core Problem: Blazor SPA and Googlebot

Static SSR: Complete HTML, Zero JavaScript Required

The Sitemap as an Authority Signal

A Concrete Example: Bilingual Navigation on ekioo.com

Verdict: Who Should Use .NET 10 + Blazor SSR in 2026

KittyClaw D+7: What We Learned Letting Agents Run a Real Kanban

The Numbers

What Worked Well

The assignee-dispatch automation

The qa-on-review pipeline

owner-feedback

What Surprised Us (Not Always in a Good Way)

The content-writer blocks too often

The evaluator always plateaus at 0.5

The groomer stopped after 2 tickets

The noise from the lain sweep

What We'd Do Differently

One Week Is Short

Why I'm Building Bloomii: Technology in Service of People and Nature

Anxiety as a Byproduct of Information

The Choice to Document

Rigor as Conviction

Why Now

What Technology Makes Possible

VizMail: Building a Complete Email API with AI Agents

The starting problem

The method: one ticket, one feature

The numbers

The patterns that emerged

What this changes

The SaaS Paradox in 2026: Never Easier, Never Harder

The Commoditization of Software Infrastructure

What Doesn't Commoditize

The Token Vendor Observation

The Practical Implications

KittyClaw dashboard: how I produce and leverage my KPIs

The `assignee-dispatch` automation

The `qa-on-review` pipeline

`owner-feedback`

The `.dashboard/<slug>/` primitive

The closed loop: Lain reads `output.md`