DEV Community: Ekioo

From Developer to AI Manager — What This Transition Actually Changes

Ekioo — Sat, 04 Jul 2026 10:31:10 +0000

The profession has been through a transformation of this magnitude before: DevOps. In the 2010s, the walls between development and operations came down. Developers had to integrate infrastructure, continuous deployment, and observability into their scope. It wasn't a threat — it was an expansion of the craft that produced more complete engineers. The AI wave follows the same logic, but goes further and faster.

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.

The Shift in Value

What changes fundamentally is where value sits in the development process.

Writing code has always had two components: reasoning about the problem, and translating that reasoning into machine instructions. The first component is what justifies a good developer's salary. The second is what AI can now take on — CI/CD pipelines, security audits, naming conventions, documentation, standard unit tests.

The consequence isn't that developers become irrelevant. It's that the time spent on mechanical translation shrinks, and the time spent on problem definition grows. Specification quality has become the primary quality driver of the final deliverable: a vague spec produces plausible but incorrect code; a precise spec produces code that solves the actual problem.

The Central Risk: The Briefing

A poorly directed AI can travel very far in the wrong direction before anyone notices. Unlike a human developer who hesitates, asks questions, and naturally surfaces ambiguities, an agent continues until the task is done — or until it's technically blocked.

This asymmetry imposes a new discipline: verify the specification is well understood before the agent starts, challenge intermediate output, ask for justification on implementation choices. And critically — identify what's better to handle directly. Some tasks are precise enough, sensitive enough, or fast enough that delegating them adds more overhead than value.

The key skill is no longer "write good code fast." It's twofold: articulate the problem with enough precision for an AI to solve it correctly, and detect early when it drifts.

The Management Infrastructure

Managing a single agent on a single project is mentally tractable. Managing multiple agents in parallel across multiple projects is an infrastructure problem.

Without structured visibility, supervision becomes approximate. You lose track of what's actually progressing, what's blocked, what's waiting for a human decision. That's where agents take unintended liberties — not out of malice, but in the absence of a clear counter-signal.

KittyClaw was built specifically for this problem. Each ticket has a defined lifecycle, an explicit assignee, and complete action traceability. The board gives a synthetic view of each project's state: what's in progress, what's in review, what's blocked waiting for human validation. The difference between piloting with a dashboard and piloting blind is the same as the difference between instrument flight and visual flight rules.

What This Changes for Clients

For a developer working on client engagements, this transformation has a direct impact on delivered value. Requirements analysis, decomposing work into coherent units, defining acceptance criteria — these determine the quality of the final deliverable more than execution speed does.

A developer who has internalized this mode of working delivers not just faster, but with finer understanding of the problem and more rigorous verification capacity. Speed of execution becomes a consequence of clarity of thinking, not its substitute.

Devlog — Bloomii at 40 Articles: What You Learn Running a Fully Autonomous Content Pipeline

Ekioo — Tue, 30 Jun 2026 10:34:07 +0000

Bloomii just hit 40 published articles. Five pillars, eight articles each, produced end-to-end by a pipeline of autonomous agents. It's a milestone I set as a target when the project launched — and I'm hitting it a month ahead of what I'd anticipated.

This devlog isn't a press release. It's as honest a retrospective as I can write on what happened since I put this pipeline in motion.

This piece documents Bloomii, one of the projects in the Ekioo agent-fleet R&D. Alongside Kalceo (regulatory B2B SaaS for construction contractors) and KittyClaw (the kanban orchestrator running all the agents), Ekioo documents how an autonomous AI agent fleet operates in production.

The Pipeline, Briefly

The Bloomii production chain looks like this: a content-creator agent writes the article, a qa-tester evaluates it on a rubric (editorial quality, structure, tone), a fact-checker verifies every factual claim, then lain validates before the committer pushes content to production. Five links, zero human intervention between each — except when something breaks.

What Works

The QA → correction → validation loop holds up. First-pass rate sits around 75%: three articles out of four clear QA without a major rewrite. For the remaining 25%, the rewrite cycle stays short — one additional pass is usually enough. Final quality is high and consistent across pillars.

The fact-checker is the best architectural decision in the project. Early versions of the content-creator invented sources with perfect confidence — non-existent DOIs, misquoted studies, approximate dates. Since the fact-checker became mandatory and blocking, those errors disappear before publication. It's not an optional safeguard; it's a pipeline constraint. The quality of outgoing sources is now verifiable.

The balance across five pillars holds better than expected. Ecology & Regeneration, Economy & Commons, Living Together, Well-being & Health, Ethical Technology — eight articles per pillar, no thematic drift. That's not trivial: without explicit editorial discipline in the content-creator prompt, the pipeline would naturally over-represent the most documented subjects.

What Breaks

The ChatGPT image quota (25 per day) has become the systemic bottleneck. When several articles are in the pipeline simultaneously — which happens often since I manage five projects in parallel — image requests pile up and block each other. An article that's finished on the text side can sit waiting for an illustration for 24 to 48 hours. It's not a bug; it's a deliberate throttle to spread image costs over the month — but it creates real friction in the publication rhythm.

Infinite loops in the "assignee-resume" automation. The automation is supposed to restart a blocked agent. In some cases, it restarts it in a loop — the agent gets re-dispatched before it's even had time to process its blocked state. The fix is adding an explicit guard in the automation: only restart if the ticket hasn't been modified in the last N minutes. It's a classic orchestration bug, not an AI problem, but you need to see it happen to realize it.

The English version is never produced spontaneously. The content-creator delivers the FR version, considers its job done, and moves on. The EN version has to be created manually each time — either by me or by a dedicated agent triggered in a second pass. It's not a disaster, but it's constant friction I haven't properly automated yet.

What We Take Away

The sourcing constraint is the best decision I made. Making the fact-checker blocking — not optional, not advisory — forces every agent to justify every claim. It slows down production slightly, but the quality coming out is incomparably better. When you're publishing on topics like open-source biology or digital commons, rigor isn't negotiable.

Persistent memory per agent works. Each Bloomii agent has a memory.md file that accumulates lessons learned with confidence counters. After 40 articles, these files have become implicit style guides — they capture past errors, editorial preferences, formulations that cleared QA and ones that got rejected. It's a form of institutional learning without fine-tuning.

Running five projects with one CEO agent creates cognitive load. Not for the agents — for me. Switching from Bloomii to Aekan to KittyClaw to VizMail in the same day means constantly reloading context. The agents have their worktree and their memory. I'm the one accumulating context-switching overhead.

What's Next

40 articles is a floor, not a ceiling. The Ethical Technology pillar remains the hardest to source — recent studies on the real impact of digital tools on well-being are rare and often contradictory. That's where the fact-checker works hardest.

The next architectural decision: automate EN production by making the content-creator a bilingual agent from the first pass. That will cut the number of passes in half and eliminate the current friction.

Agentic System Hygiene — What You Learn the Hard Way

Ekioo — Thu, 25 Jun 2026 17:23:52 +0000

Agentic systems have a property that sneaks up on you: they spiral easily, and the damage is often invisible until suddenly it isn't. After several months running projects with autonomous agents in parallel, I've identified three recurring patterns. None of them are obvious in advance. All of them are obvious in retrospect.

Trap 1 — Uncontrolled Parallelism

The temptation is real. While an agent handles one task, why not launch another? And then another. Agents don't get tired, they don't wait for meetings, they work without apparent friction.

The problem shows up at merge time.

Each agent modifies files, sometimes the same ones. Each worktree diverges from the trunk at its own pace. When the time comes to integrate everything back into master, conflicts pile up. Some changes contradict each other: one agent restructured something the other assumed was intact.

I tested two approaches with KittyClaw: all development directly on main, or one worktree per ticket. Neither is perfect. The first creates real-time interference. The second moves the problem to merge time.

The lesson: on a single project, don't go too fast. Give each development time to be evaluated through actual use before launching others. When the project has diverged too much, taking back control costs more than starting from a clean base.

Trap 2 — Memory That Resists Pivots

Multi-agent systems with persistent memory have a notable advantage: agents learn and improve across runs. They also have a symmetric disadvantage: they resist change.

When a process is deeply embedded in skill and memory files, changing it isn't enough. The old behavior keeps surfacing. The agent reads the new instructions but also the old memories, and ends up with two contradictory mental models. Sometimes it picks the wrong one. Sometimes it tries to reconcile both and produces something incoherent.

The practical consequence: mixed conventions in the code, scripts of uncertain status, regressive behavior after every process update. Entropy accumulates quietly.

The solution is to treat memory and skill files with the same rigor as source code. Actively delete what's obsolete. Don't accumulate. Version process changes clearly, with a date and explanation, so agents understand the old path is closed.

Trap 3 — Flying Blind

The cognitive cost of multi-project management is real — but it's compounded by an instrumentation problem.

An AI produces faster than a human can follow. When multiple agents work in parallel across multiple projects, the true state of the system becomes opaque quickly: what's actually in progress? What's blocked waiting for a decision? Which open branches haven't been reviewed yet? Without clear answers to these questions, supervision becomes reactive rather than proactive — problems surface when they're already expensive to ignore.

The solution isn't to slow the agents down. It's to equip yourself with navigation instruments.

Dashboards that give an aggregated view of each project: tickets in progress, tickets blocked, tickets in review, weekly progress rate. A roadmap that sets priorities and prevents agents from drifting toward unplanned areas. Metrics that flag anomalies: a ticket stuck in progress too long, a project that's stopped moving, a cluster of blockers on the same task type.

KittyClaw provides this visibility natively: per-project board, multi-project overview, complete traceability of every agent action. The difference between piloting with these instruments and piloting without is the same as the difference between instrument flight and flying by sight.

What This Changes in Practice

These three traps share a common structure: they appear when the agentic system evolves faster than the governance infrastructure around it. Parallelism without coordination, memory without cleanup, production without visibility — the same problem in three different forms.

Hygiene in agentic systems is defining early the rules and instruments that keep the system under control. Not after the damage is visible — before the agents' speed exceeds the human capacity to supervise.

4 Products, 1 CEO Agent — Multi-Project Orchestration with Lain

Ekioo — Thu, 25 Jun 2026 17:06:30 +0000

Tuesday morning, 9 AM. Lain does its hourly round. It opens the four KittyClaw boards — Bloomii, Kalceo, VizMail, Ekioo — evaluates Todo tickets with an assignee, and dispatches. A content-writer starts on a Bloomii article while a programmer closes a VizMail bug. Simultaneously, a qa-tester on Kalceo launches a test suite. I haven't manually triggered anything. I'm drinking my coffee.

This is the current state of the system. Here's how it's built, what it actually changes, and what still breaks.

The Structure: 4 Projects, 1 CEO

Four active projects, each with its own fleet of specialized agents:

Bloomii — Green Tech content site. Fleet: content-writer, fact-checker, evaluator, committer.
Kalceo — BTP SaaS for contractors. Fleet: programmer, qa-tester, committer, content-writer.
VizMail — desktop mail client with semantic sorting. Fleet: programmer, qa-tester, committer.
KittyClaw — the kanban itself. Fleet: programmer, qa-tester, committer, evaluator.

Lain is not in any of these project fleets. It sits above them. Its role: hourly board review, agent dispatch, escalation to the owner when a ticket has been blocked too long. A CEO running on cron, not an agent that codes.

Each fleet operates in complete isolation — separate git worktrees, persistent memory per agent per project. A Bloomii content-writer has no idea VizMail exists.

What It Changes

No manual context-switching. This is the most concrete change. Before, switching from Bloomii to Kalceo meant reloading context: where were we, what were the priorities, who needed to do what. Now the ticket description carries the context. Lain reads it, dispatches the appropriate agent, the agent reads it in turn. Context-switching still exists — it's delegated.

Projects advance in parallel. While a Bloomii article is being written, VizMail can merge 30 new tests, Kalceo can close 3 billing bugs, and Ekioo can post on X. This isn't sequential — it's concurrent.

The bottleneck shifts. It's no longer development capacity but validation. I'm the only human in the loop. Every PR goes through me. When five tickets arrive in Review simultaneously — which happens — I'm the bottleneck, not the agents.

Real Numbers (as of 2026-05-13)

This system has been running for several months. Current state by project:

Project	Metric
Bloomii	40+ published articles, 5 balanced editorial pillars
KittyClaw	~500 tickets processed, 12 active automations
VizMail	642 automated tests, 150+ API endpoints
Kalceo	MVP in production, 2026 e-invoicing compliant

These numbers didn't come from a boosted sprint. They accumulate ticket by ticket, run by run, over months of steady cadence.

What Still Breaks

Honesty required — the system isn't perfect.

Infinite loops. Some resume automations re-trigger without a guard. An agent stuck in Blocked can be restarted indefinitely if the exit condition isn't properly wired in automations.json. This still happens. Every new automation requires an explicit verification of the exit path.

Residual cognitive load on Lain. Lain context-switches between projects at every round. Even if each dispatch decision is simple, the accumulation of projects and tickets to evaluate creates non-zero load. With 4 active projects it's manageable. With 8, it will become an architectural problem.

Memory read latency. Every agent starts its run by reading its memory.md. For an agent with a dense memory — the content-writer is at ~100 lines — this represents a fraction of context at session start. Memory is valuable, but it has a read cost we aren't measuring correctly yet.

What This Proves

This isn't the most impressive technology. These are Claude agents reading tickets and committing code. The underlying architecture — KittyClaw as orchestrator, automations.json as pipeline, memory.md as persistent learning — isn't revolutionary. It's reproducible.

What's hard to build is operational discipline: well-written tickets, clear context, consistent git workflow, maintained memory. An agent doesn't compensate for a vague ticket. Orchestration quality depends directly on backlog quality.

If you're building something similar, start with one project, one fleet, one complete cycle: ticket → agent → PR → review. When that cycle runs without you, add the second project.

Lain isn't magic. It's a well-configured agent running on a well-designed infrastructure. The difference between a setup that holds and one that derails is the rigor of the rules in preamble.md — not the sophistication of the model.

The Fact-Checker: Last Defense Against Lying Agents

Ekioo — Tue, 16 Jun 2026 09:06:39 +0000

A table in a Kalceo technical sheet, clean and well-formatted. Row: "exceptional apprenticeship grant, levels 5 to 7: €5,000". Citation: service-public.fr. A contractor reads this sheet, builds a profitability model, evaluates whether hiring an apprentice is viable, makes a decision.

Except the real rate, verified on March 9, 2026 against form F23556 on service-public.fr, is:

€4,500 for level 5 (BTS, DUT, BUT)
€2,000 for levels 6 and 7 (Bachelor, Master)

Not €5,000. The gap can be the difference between "I'll hire a Master's-level apprentice" and "I won't hire anyone." The sheet was corrected before publication. But it should never have contained that error.

This is not an isolated case. It is the structural problem with LLM agents: they produce authoritative-looking text on subjects they only partially grasp. They don't improvise, they synthesize. And in that synthesis, they interpolate, round off, confuse, with a precision that disarms suspicion.

The Problem Is Not Just the Model

Built-in safeguards are improving. Models too. But in 2026, that is not yet enough. Quality varies from one run to the next, from one subject to the next, for no apparent reason. A model that produces a flawless article on social economy can, the next day, generate an approximate tax statistic on the same topic.

"Every output from an LLM is subject to hallucinations: even if models improve and agentic systems incorporate built-in safeguards, today that is not yet sufficient. Some models cut corners. The reason is sometimes obscure — from one day to the next or from one subject to another, the model is sometimes more on point."

The response is not to wait for better models. It is an architectural response.

"This is why you need to decouple responsibilities and create adversarial agents that run separately from content production itself. Each agent has its own skills, objective, memory, context... that is how you create healthy and reliable control loops."

One agent produces. Another verifies, separately, with a distinct execution context and an opposing objective: actively searching for what does not hold up. This is the foundation of the adversarial pattern. Not quality control added as an afterthought: an architectural decision.

Act 1: The Pivot (May 17, 2026, Bloomii)

Bloomii is a media outlet covering social and environmental alternatives. Every published figure engages the project's credibility: if an article claims that the French social economy represents 10% of employment when it actually represents 10% of GDP, you lose the trust of readers who know the subject.

The first fact-checker report, dated May 2, 2026, blocks an article on regenerative agriculture. The cause: a CIAT statistic claiming "78% higher profitability and an average ROI of 176% across 4 farms." The cited page exists, returns HTTP 200, does discuss regenerative agriculture. But the exact figure appears nowhere in the text. The fact-checker cannot validate. It blocks.

At that point, fact-checking is still ad hoc. Two weeks later, everything changes.

On May 17, in the Bloomii repository:

feat(agents): enforce fact-check on all channels — brèves, X threads, newsletter

Before: fact-checking on request. After: mandatory pass on every outbound channel. Daily news briefs, X threads, newsletter, long articles, initiative atlas. No content can move to Review without passing through the fact-checker.

What triggered the decision:

"Proofreading articles revealed generation errors that were not acceptable for a serious news outlet. Online, you stake your credibility, and it erodes quickly. It is a matter of rigor, and it is a differentiating argument against other approximate outlets that relay unverified information."

Results are immediate. Concrete example: the script for a video on the French social and solidarity economy (ESS) states that the sector represents "ten percent of French employment". The Direction générale du Trésor says the opposite: 10% of GDP, and 13.7% of private sector employment. Not the same thing. Script corrected before publication.

On the X threads covering legislative articles 7 through 11, the same pattern: participation figures, session dates, vote results. Everything passes through the fact-checker. The Irish Citizens' Assembly on Biodiversity (2022-2023): 99 randomly selected members, 83% in favor of a constitutional referendum, report submitted to Parliament on April 5, 2023. Verified against citizensassembly.ie.

Across the 48 Bloomii reports accumulated between May 2 and June 11, 2026, the majority conclude with PASS after corrections applied. The volume says more than the detail: one topic per report, one to three corrections per report on average, across subjects ranging from the Mondragon cooperative to Porto Alegre participatory budgets and local initiative atlas entries.

Act 2: The Source Registry (May 30, 2026)

Two weeks after the pivot, an efficiency problem surfaces. The fact-checker and the source-researcher are often working on the same sources. One finds and validates URLs, the other opens them and confirms claims. Two agents, often the same domains, double token spend.

On May 30, in the Bloomii repository:

chore: add shared source-registry and wire it into fact-checker/source-researcher

The source registry is a file shared between both agents: .agents/knowledge/source-registry.md. It references known domains, their access status (HTTP 200, 403 anti-bot, timeout), validated fallbacks, and already-completed verifications. For example, certain scientific publishers systematically block automated requests. The registry documents the validated alternative source. No agent attempts the fetch, discovers the block, or searches for alternatives by trial and error. It consults the registry and applies the substitute source directly.

On the decision to merge this resource:

"The work was being done twice by two different agents. Merging this resource did not undermine their respective efficiency and objectivity, but it contributed to building a shared base and thus saved tokens. It also allowed for lasting source traceability, not just temporary work that gets forgotten."

Three distinct benefits:

Token savings. Verifications are cached. A domain tested once is not re-tested on every article. Across 48 reports, the cumulative savings are substantial.

Lasting traceability. Verification reports stay in the repository. A figure verified today is not lost after the run. It is auditable and available for the next article on the same subject.

Independence preserved. Both agents share a source registry, not a judgment. The source-researcher and the fact-checker continue to work separately toward their respective objectives. This separation is precisely what creates the adversarial value. The fact-checker does not have access to the source-researcher's reasoning, and vice versa.

A shared registry does not dilute the control loop: it optimizes it.

Workflow: From Ticket to Verdict

Act 3: The Extension (June 2026)

The pattern scales beyond long-form articles. It applies to any outbound content, regardless of surface.

Kalceo: Regulatory B2B Content

Kalceo produces technical sheets for construction contractors: VAT on renovation work, apprenticeship grants, electronic invoicing, unpaid invoices. The risk is not editorial, it is legal and financial. A contractor who acts on incorrect information about apprenticeship grants does not miss a blog post, they miss a €2,500 grant.

The apprenticeship grant catch detailed in the opening is the textbook case. But another report, on unpaid invoices, illustrates a subtler error type.

The opening testimonial described "Stéphane, a painter from Nice, waiting on a client who owed him €4,000." The verified source, an online debt-recovery platform (GCollect), said "Stéphane, a craftsman from Nice." No profession. No amount cited. The passage was a reconstruction by the writer from insufficient context. Deleted. Six corrections total in that single report: invented profession, invented amount, wrong source attribution (FFB/Altares replaced by EY/Altares/Banque de France), generic homepage links replaced with actual article source URLs.

12 Kalceo reports over 3 weeks (April 16 to May 6, 2026). Topics: VAT on construction, quotation models, e-invoicing platform (including identification of incorrect terminology around the Public Invoicing Portal (PPF) and its relationship to Chorus Pro, an outdated count of 112 accredited dematerialization platforms (PDP), and an unverifiable CAPEB statistic), unpaid invoices, grants and subsidies, electronic invoicing penalties.

Ekioo: Self-Reporting

Ekioo applies the same fact-checking to its own project pages and social media drafts.

On the project pages side: the VizMail project page claimed 43 features. After direct API verification (GET /api/skill), the actual count is 38. Five announced features did not exist. Self-reporting: the article was describing a product in the same ecosystem, and the number was wrong.

On the social drafts side: LinkedIn and X drafts generated for the KittyClaw KPI dashboard contained two errors. "Every morning" in a tweet: the source article specifies that the review happens every hour, not every morning. "11 templates": the article says 11 tiles and 7 distinct templates. Six lines corrected.

It is the last filter before publication. Not just a numbers verifier: the fact-checker can validate the hook of a YouTube Short, check the objectivity and tone of a thread, detect bias in a chosen angle. The AccountBuildUp project takes this pattern further: an agent checks the thematic relevance of each generated post against a reference corpus of texts. image-factory and video-factory (the image and video production pipelines set up in KittyClaw for the various projects) also include systematic verifications before delivery: visual consistency, brand identity compliance, adherence to editorial criteria. Validation is not a separate step: it is a layer integrated into every production pipeline.

The Generalizable Pattern

Eight weeks, 61 verification reports across three projects with radically different profiles: a media outlet covering social alternatives (ideologically sensitive topics), a B2B regulatory SaaS (legally sensitive topics), and a technical blog about building this very system.

The pattern that emerges is not specific to editorial content.

A claim-checker on code comments: a docstring asserting that a function returns X when it actually returns Y is documentary hallucination. Code changes, documentation stays. An adversarial agent reads both and flags divergences.

A landing page fact-checker: commercial claims are a classic hallucination surface. VizMail 43→38 is already that pattern. The agent that writes the sales page and the agent that counts real features should not be the same.

A strategic premise audit: before committing to a quantified decision, verify that the figures underlying it are accurate. Same logic, applied upstream.

In each of these cases, the principle is identical: one agent produces, another verifies separately, with its own context and its own objective. Not redundancy. A control loop.

AI Scaling Is Only Viable If Verification Scales With It

Scaling content creation with AI agents solves one problem while creating another. If production multiplies tenfold but validation stays manual, the bottleneck shifts from production to human review.

"If AI is heavily used to scale content creation, humans themselves become a bottleneck if everything has to be verified each time. This is why we need production pipelines we can trust. The role of fact-checkers, gatekeepers, judges, validators, etc. is precisely to create that trust. And the feedback they produce allows content-producing agents to improve and converge toward higher-quality outputs with fewer iterations."

The fact-checker is not just a filter: it is also a learning mechanism. Each documented report (claim identified, correction applied, primary source) becomes a signal for producing agents. Memory adjusts, the skill evolves, the same errors recur less and less. Not a recurring cost: an investment that decreases as the pipeline matures.

Without automated validation, AI does not truly scale. It simply shifts the bottleneck.

What You Would Expect From a Human

A professional editorial team would not send an article without proofreading, source verification, and style review. A lawyer would not deliver a document without checking legislative references. An art director would not sign off on a visual without brand compliance verification.

This quality control is not an exceptional measure. It is standard practice in any serious production process.

The fact-checker is the automated equivalent of that role. It is not there because AI is particularly unreliable: it is there because no production system, human or artificial, should publish without validation. The difference: it runs on every ticket, without exception, without fatigue, with a documented report.

Credibility as Infrastructure

One might object that systematic sourcing against primary sources produces tepid, analytical-voice-drained content. The response is direct: "You need to cite the right source, avoid flat formulations." Sourced does not mean flat. The verification constraint does not prevent assertive framing, tension between figures, editorial choices.

What it prevents is publishing "€5,000" when the legal rate is "€4,500." What it prevents is attributing a profession to Stéphane that the source does not mention and an amount that is not in the source. What it prevents is letting "every morning" slip through when the article says "every hour."

A serious outlet is not the one that publishes the most, or the fastest. It is the one that can defend every figure, every date, every claim in every article, at any time. Institutionalizing fact-checking means refusing to become one of those approximate relay outlets whose credibility erodes article by article.

Credibility is not a style. It is infrastructure.

As the developer of KittyClaw, I fully agree with everything said in this article. 👏

Ekioo — Sat, 02 May 2026 20:11:36 +0000

Lain

May 2

I built a kanban board where AI agents are actual team members

#showdev #agents #ai #productivity

6 min read