Forem: Yves Van Goethem

Faru: The Kanban Board for AI Agents

Yves Van Goethem — Thu, 23 Apr 2026 10:46:00 +0000

A few weeks ago, we replaced Jira with a folder of markdown files. We've coined it faru and we've been using it every day since. It stuck. So we put it on GitHub.

Why we built it

It's not that we built a tool to give our AI agents a backlog. It's about AI agents making their work visible to us.

Our agents write markdown files into a backlog/ folder in our docs repository. A bit like people would use a Google Drive, except it's git. Our IDEs, agents and tools already have that folder open. Git already syncs it.

We didn't want to integrate with another platform. We wanted the board to just be part of the flow we already had. Open the folder, see the cards. Save a file, the board updates. That's it.

At fluado, that's also what we try to do for our customers. Don't bolt a new platform onto someone's workday. Fit into what's already there.

We put it on GitHub because it might be useful to someone. Or at least inspire them to build their own version.

What it actually is

One server.js file. Zero npm dependencies. You point it at a directory, it reads the markdown, renders 3 columns.

npx github:fluado/faru

Cards are folders. Each folder has markdown files with YAML frontmatter. Drag a card to move it. Click a title to rename it. Every change gets committed and pushed. The board polls the remote every 5 seconds. Two people looking at the same repo see the same board.

Click a card and you get a detail view with metadata, milestone progress, comments, and a list of all the files in that folder. Click any file and it opens in your editor. The board doesn't try to be an editor. Your IDE is the editor.

3 columns

faru has 3 columns. You can't add more.

I know. It's on purpose.

"In Review" is WIP. "Blocked" is a problem to fix, not a lane to park in. "Ready for QA" is a queue, and queues are where tickets go to die.

A card is either not started, being worked on, or done. If you need more states than that, read up about lean methodologies.

What we're not doing

We're not building a SaaS. We're not going to add Gantt charts or time tracking.

We also won't maintain a community around this. We don't have the bandwidth to review PRs or triage issues.

If you open an issue with a good idea, we might pick it up when it aligns with what we need. No promises.

Fork it, break it, make it yours.

Who this might be for

If you work with AI coding agents and you want them to manage work through files the way they manage code, faru does that.

If you're a small team, maybe just 2 people and some agents, and you want visibility without a subscription, this might work (it does for us). It runs locally. Your data stays on your machine and in your git repo.

If you're a team of 50, this probably isn't for you.

We built it for us. We shared it because why not.

github.com/fluado/faru

Want your own AI agents? Talk to us. We build AI agents that actually work hand-in-hand with medium-sized businesses, without the bloat.

If you want to follow what we're building at fluado, find us on LinkedIn or Bluesky.

Jira for AI Agents & Humans

Yves Van Goethem — Fri, 03 Apr 2026 08:47:17 +0000

First things first: don't worry, I didn't re-invent Moltbook here.

Every startup I know runs on 3 tools too many. A board here, a Notion doc there, a Slack thread that became the de facto spec. At fluado, where we build AI agents for entreprise, a new layer crept in over the past weeks: agents writing markdown into our docs repo. Sprint tickets, completion reports. Dozens of files. The filesystem became the source of truth. The project board didn't.

Arbo and I talk every day. Multiple times. But conversations don't leave a trace you can point at. Jira was supposed to be that trace. When we opened it this morning, it still showed the state from 4 weeks ago. Nobody had touched it.

I wrote previously that AI is a productivity multiplier if you already have your house in order. Turns out, that includes your project board.

So I pitched Arbo: what if we build a tiny board that just reads the markdown files that already exist? A window on top of reality.

He was skeptical. I wasn't sure it would survive the afternoon either. But the alternative was spending the morning updating our Jira board again, potentially going stale within the week.

By late afternoon, Jira was gone. All tickets migrated. Both of us and our agents working in the same board.

The board

Our agents already work in markdown. They create files with YAML frontmatter and write reports. So why funnel that through a SaaS board designed for humans clicking buttons?

Every task lives in a folder inside backlog/. The folder name encodes date and category. Inside, a constellation of markdown files:

backlog/
├── 2026-03-26-CHAT-UX/
│   ├── chat-ux-milestones.md    # the plan
│   ├── chat-ux-tickets.md       # broken into tasks
│   ├── CUX0-report.md           # agent completion report
│   └── CUX1-report.md
├── 2026-03-27-AGENT-I18N/
│   ├── agent-i18n-milestones.md
│   ├── agent-i18n-tickets.md
│   ├── I0-report.md
│   ├── I1-report.md
│   └── i18n-audit-report.md
└── 2026-04-01-OPS-DEPLOY-STAGING/
    └── CARD.md                   # simple card, no sub-tasks

The milestones file is the plan. Tickets break it down. Reports are what the agent produces when it finishes a milestone. CARD.md is for simple tasks with nothing to break down. Each folder's canonical markdown file carries the YAML frontmatter the board reads:

---
title: "Chat UX Improvements"
type: product
status: wip
assigned: yves
created: 2026-03-26
edited: 2026-04-01
---

An agent creating a task does mkdir and writes a markdown file with the right frontmatter. The schema is simple enough that the agent infers it from existing files in the folder. When it gets the frontmatter wrong, the board just skips the file. I notice in the git log and fix the YAML in 10 seconds.

I scroll through the folder tree in my IDE. The board renders the exact same structure in the browser. Three columns: todo, wip, done. Drag a card to change its status, or click a title to rename it inline. Every card has an "Open in Editor" button that pops the file.

If someone edits a backlog file in the IDE, the board server notices immediately. A file watcher monitors backlog/, debounces for 5 seconds, auto-commits to git. You save, git syncs.

The sync

What's the simplest thing that could keep 2 people and a handful of agents looking at the same state? Git.

Every board action triggers an immediate commit and push:

  [15:42:06] 📝 committed: move CHAT-UX to done
  [15:42:07] ⬆  pushed
  [15:43:12] 📝 committed: create OPS-DEPLOY-STAGING as todo
  [15:43:13] ⬆  pushed
  [15:44:30] 📝 committed: rename AGENT-I18N
  [15:44:31] ⬆  pushed

For incoming changes, the server polls git ls-remote every 5 seconds. One SSH roundtrip, one SHA comparison. When the remote has new commits, it pulls and logs what came in:

  [15:45:10] ⬇  synced from remote:
       abc1234 board: move AGENT-I18N to wip
       def5678 board: update 2026-04-01-SURFACE

The browser updates via Server-Sent Events. The board re-renders silently, so if you're mid-way through editing a card or filling in a form, nothing gets nuked. I learned that one the hard way. First version did location.reload(). :D

The same flow works in reverse. When an agent finishes a milestone, it commits a report to the backlog folder, pushes to git. 5 seconds later, the board picks it up and the new file appears in the card's detail view. I don't have to ask the agent if it's done. I see it on the board.

The board code itself lives in the same repo. It runs through nodemon, so when one of us pushes a fix to the server, the remote poll pulls it in, nodemon restarts, and the new frontend arrives via SSE. I changed the CSS at 15h00. By the time I switched to my browser tab, the new styles were there. Arbo saw them too.

Cards are sorted by modification time, descending. Most recently touched card floats to the top. I tried implementing manual drag ordering with fractional indexing. Used it for 5 minutes. Threw it away. The filesystem already knows what I'm working on.

What actually changed

We kept working the way we already worked. Arbo & I in our IDEs and board, agents committing to backlog/. Git ties it all together. The whole stack is vanilla HTML/CSS/JS, zero build step, zero npm dependencies. http.createServer, some YAML parsing, and fs.watch.

A note on scale

I keep seeing "SaaS is dead, AI can build anything" takes in my feed. This works for a team of 2 humans and a handful of agents. I have no idea if it can or should replace Jira in a team of 10. Will this board survive 6 months? I don't know.

What I do know is that we spent a morning building it and an afternoon using it. By evening, the board had 14 cards across 3 columns. Arbo dragged one to WIP while I was writing this. I saw it move.

We didn't replace Jira because we were unhappy with it. We replaced it because the real board already existed in our filesystem. Jira was a copy of it that nobody maintained. So we deleted the copy and put a window on the original.

The tool fits how we work because we built it around how we work. That's not a universal lesson. It's ours.

If you want to see what we build next, subscribe to the newsletter or follow us on LinkedIn, Mastodon, or Bluesky.

Got a process that needs an agent? Let's talk.

The AI agent nobody offboarded

Yves Van Goethem — Wed, 11 Mar 2026 15:02:35 +0000

A team sets up an AI agent. The agent needs access to internal tools, say Slack, so someone creates an API key with broad permissions. "We'll scope it later." The agent works. Everyone moves on.

Six months later, nobody remembers who created that key. What it can reach. Whether the permissions were ever reviewed. They weren't.

I know this because it happened to us. Two people building an AI product, and we couldn't trace one of our own API keys back to its source. Couldn't tell if it was production or staging. We are a team of 2. Now picture a company with hundreds of developers and dozens of agents, each with their own credentials. None of them expiring. None of them reviewed.

Ring any bells?

The numbers

A Cybernews survey from August 2025 found that 59% of employees use unapproved AI tools at work. Of those, 75% share sensitive data with them. Not accidentally. Routinely.

The UpGuard "State of Shadow AI" report from November 2025 puts it higher: 81% globally. And the part that got me: 88% of security leaders admitted to using unauthorized AI tools themselves. The people responsible for enforcing governance are bypassing it.

The problem is that none of this was designed for machines.

Identity management was built for people. People log in, work, log out. Their access has a lifecycle: onboarding, role changes, offboarding.

AI agents don't follow any of that. Static tokens, broad permissions, persistent access. They run around the clock. They don't trigger the same flags a human account would.

And when one of those credentials gets compromised, it doesn't leak one user's data. It leaks whatever that agent could reach.

It gets worse

In February 2026, security researchers at Koi Security audited ClawHub, the official skill marketplace for OpenClaw. Out of 2,857 skills, 341 were malicious. Roughly 12%. One attacker alone uploaded 677 trojanized packages. Some had thousands of downloads before anyone noticed. The malicious skills stole SSH keys, browser credentials, wallet data. Some installed info-stealers like Atomic macOS Stealer. All on a marketplace where any GitHub account older than a week could publish.

Same month, researchers found over 8,000 MCP servers publicly exposed on the internet. No authentication on admin panels. Default configs. Debug endpoints wide open.

Shadow IT was already a governance problem. Shadow AI is worse. Agents don't just store data or move it around. They make decisions. They create records, send emails, trigger workflows, call external APIs. That's the entire point.

You can't do forensics on a system you didn't know existed.

What we're doing about it

The fix isn't to stop using agents. It's to build governance, audit trails, and compliance infrastructure into the agent itself, not bolt it on after. The kind of thing nobody wants to build, and everyone will eventually require.

Try this. Pick one of your AI agents and list everything it has access to. Every API, every integration, every credential. If you can do that in under an hour, you're ahead of most companies.

If you can't, you have no idea what to revoke when something goes wrong. And something always goes wrong.

You've seen the LinkedIn posts. Someone's agent racked up a five-figure cloud bill because a leaked key let it spin up resources. Someone else had their keys stolen and is writing about going bankrupt. These show up in my feed weekly. At some point, the cautionary tales stop being about other people.

It's why we started fluado. Because the tooling to do this right doesn't exist yet.

Would love to hear your thoughts about this topic :)