The Luge method

The biggest working hour of the day is two in the morning. Nobody is at the screen.

Luge is a platform where AI colleagues work on the same objects as humans — cards, notes, tables, meetings. It's built by a single person, who runs it on itself: backlog triage, ticket writing, tech watch and the shaping of each day all go through the product under construction. A good part of it happens while he sleeps.

This article is not a sales demo. It describes a real operation, read off the instance: exactly where the line falls between what an agent does alone and what waits for a human decision, the written discipline that delegation demands in return — and what it never replaces.

Read on August 25, 2026 · numbers and prompts taken from the instance · test benches excluded

The counters, on the day of the reading:

• 5 boards
• 1,251 cards created
• 13 active tasks
• 5 active workflows
• 89 skills
• 8 tables

The context

One developer, one platform, one fleet

Luge is a colleague you add to the team — with a memory, skills, access to the organization's tools, and the job of doing the work rather than talking about it. It's neither a conversation assistant nor a gateway to existing messaging apps: it's a complete workspace, where channels, tasks, documents and meetings are native, and where agents act in it on the same footing as people.

The product covers seven territories: conversations and AI colleagues, voice and meetings, memory, documents and notes, boards and planning, tables and deliverables, automations and workflows — all under access, audit and compliance rules designed for sectors that demand them.

These territories don't live in a single window. Luge is reached from the browser, a desktop app, a mobile app, a command line, a development kit — and a runtime that installs on the user's machine to run a model locally, transcribe without the audio leaving, and expose that computer's tools. A partner space also lets you resell the platform white-label, under an identity other than its own.

So much for the product. The decisive fact is elsewhere, and it changes how everything that follows should be read.

What follows is therefore not an organizational comfort. It's the condition that makes the project possible. One person alone cannot re-read three hundred cards a week, empty a capture inbox every evening, analyze every watch link and write tickets documented down to the file and the line. Agents do it, inside the tool, at night.

And that imposes the opposite constraint of a team's. In a team, sloppy work eventually gets seen by someone else. Here, nobody re-reads behind you — hence written rules, explicit boundaries, and proof demanded before a card is closed. Rigor isn't a temperament preference, it's the only net.

The principle

The agent prepares the case, the human rules

The rule that organizes everything else fits in one sentence: an agent has the right to prepare a decision, never to take it in the human's place when it's irreversible or costly.

It doesn't look like much, but it's what allows a fleet of agents to run unsupervised. Every automation carries a boundary written in black and white: what it does alone, what it merely proposes. Nothing is left to the model's judgment at execution time.

A card is not a sticky note. It's a case file, written by an agent, validated by a human.

The corollary is a demand of substance: you fix at the cause. A card that proposes raising a limit rather than reducing the cost that trips it gets sent back — it's written in the tickets themselves.

The day

Marching orders

Twelve active scheduled tasks, spread across twenty-four hours. The bulk of the tidying is done before wake-up.

• Autonomous
• Waits for a human answer

1. 02:00
   PO — nightly pipeline The Product Owner opens the board: it checks the 25 cards awaiting proof of delivery, grooms thirty cards from the "to do" pile, and writes its report. It looks at neither the archives nor the cards in progress. daily · budget of 30 cards · report by DM
2. 03:00
   Inbox refinement Empties the capture inbox: every note tossed in on the fly becomes real tasks, the note is restructured in place, retitled, and leaves the queue. daily · never a note written on the side, never content lost
3. 07:15
   Review of pending notes Closes the notes whose tasks are all done, creates the ones that are missing. Anything that must go out to the world first goes through a request to the human. weekdays · never a rewrite, one note per pass
4. 07:30
   Day plan Builds the day around the meetings already there — assigned cards, personal tasks, free blocks — then submits it for validation instead of applying it. weekdays · proposal mode · never empties the day
5. 08:45
   Daily scrum The daily check-in, triggered by a one-line command that loads its whole skill. weekdays
6. 09:00
   Morning check-in Mood, energy, a note if the heart is in it. The answer doesn't vanish into the void: it's written into a table, and becomes a series you can re-read. daily · 53 entries · see "memory"
7. 09:00
   Appointments and tasks of the day Two parallel tasks: the next appointments pulled from the calendar, and the reminder of tasks in progress by direct message. daily
8. 8–16
   Email triage Every hour during the working day: sorts unread mail into "to read / action" and "deletion candidates". Deletes nothing. weekdays · nine passes
9. 20:58
   News from Québec Five to eight news items, each with its source and its link. No link, no news item: the rule is in the prompt. daily · eight outlets listed · fifteen words of quotation maximum
10. Fri.
    Tech summary of the week Takes the 128 watch cards and publishes the weekly digest in the team channel. weekly

The centerpiece

The agent that tidies the board overnight

At two in the morning, a Product Owner agent opens the main board. It starts by updating the code repository — because it's not going to judge a card's relevance without reading the code it refers to. If it can't, it forces nothing, notes it in its report and moves on.

Then it makes two passes. Deliveries first: the twenty-five cards in the "done" column are read one by one with their comment threads. Proof of delivery — a commit, a pull request, an end-to-end test? It archives. Otherwise it comments precisely on what's missing, and leaves the card alone. It never moves a card backwards itself. Along the way it flags "in progress" cards with no activity for three days, without touching them.

Then the grooming: thirty cards maximum per night, drawn from a pile of three hundred and five, starting with the new ones and then the least recently reviewed — it maintains the table that keeps track of its passes itself. For each card, four questions: is it still relevant given the code? is the description actionable? is the priority right? is it a duplicate?

Four guardrails frame the whole pass:

• Never a deletion Not a card, not a board. Archiving is reversible, deletion isn't.
• Never the cards in progress What a human is working on right now is not material to tidy.
• Every change commented On the card itself. A change without a trace is a change you can't contest.
• Idempotent Running it twice changes nothing the second time. That's what makes a re-run harmless.

Second example

From Telegram to the team channel, hands-free

Tech watch follows the same principle, applied to something mundane: reading an interesting link and not forgetting it. The human gesture comes down to pasting a URL into a Telegram conversation — from the phone, without opening a management app. Everything else chains on its own.

1. 01 A link is pasted Into the watch channel on Telegram. One link, or ten at once — batch processing is built in. Human · 3 seconds
2. 02 A card appears An agent creates the card on the watch board: a readable title drawn from the link, the URL in the card body. Nothing more. Agent
3. 03 Assigned to the AI The assignment isn't administrative: it's the trigger. A card handed to an AI in that column launches the workflow. Agent
4. 04 The link is read What it is, how it works, strengths, limits, maturity, use cases. The analysis is published as a report pinned to the card, which moves to "done". Workflow · agent node
5. 05 The summary arrives Title, four to six lines, verdict — in the team channel. And on the last line, mandatorily, the link that was analyzed. Workflow · notification node

On the counter, the day of the reading:

• 3 waiting
• 53 analyzed
• 73 archived
• 1 weekly digest

Only three cards are waiting their turn, out of a hundred and twenty-eight. The pipe doesn't clog: the last card was created at 4:03 p.m. and its analysis was published before 4:07 p.m. And on Friday, a weekly task takes the whole board back up to draw out the week's digest.

Here, no approval step, unlike the development board. The reason is consistent with the mother rule: nothing this chain does is irreversible. A failed analysis gets re-run, a card gets unarchived, a channel message gets corrected. Where the cost of error is low, the agent goes all the way on its own.

The convention

What a card contains

Tickets aren't written by hand. A command writes them, from the code, to a fixed template. The result isn't a vague intention to decode later: it's an investigation already done.

Symptom

What's observed, dated, with the exact conditions.

Reproduction

The sequence of commands that makes the problem reappear.

Expected vs observed

Two lines. What should happen, what happens.

Root cause (hypothesis)

With the files and the line numbers. That's what separates a ticket from a complaint.

Impacted areas

The files to touch, tests included.

Fix direction

Where to fix, and why not elsewhere.

Acceptance criteria

Checkboxes, measurable. Not "it works better".

Estimated effort

S, M or L — and what really costs, which isn't always the code.

_Card written by /luge-ticket-create: analysis to be validated._

That last line is the mandatory signature. It says two things: where the text comes from, and that it hasn't been validated by a human yet. A machine-written ticket that didn't say so would be a ticket you'd believe had been reviewed.

The product point

A card is a place, not a record

A case file that thorough invites questions, and that's where the card stops looking like an ordinary ticket: you can talk to it. Two doors lead to the same object, and they don't serve the same moments.

The consequence fits in one sentence: the board isn't a place you go to, it's a place that comes to you. The proof rule had already made the command-line client indispensable to delivery; here it makes it, almost as a side effect, the way to reach the work from anywhere.

This page is an example. It was written by an assistant outside Luge, equipped with the command-line client, which read the boards, the cards, the scheduled tasks, the workflows and the tables without being sent a single screenshot — and which ended up creating a scheduled task, once the go-ahead was given.

The delivery rule

Nothing is done until the command line proves it

This rule has a consequence you don't anticipate: it makes the command-line client grow at the speed of the platform. Every feature that couldn't be proven forced the addition of the missing verb. The release log keeps the trace, sometimes with the bill.

The most recent release carries this sentence at the top of its log: "a client that can prove what it announces". Fifty-nine releases published, and a good part of that growth comes from there — not from a roadmap, but from tickets that had to be closable honestly.

This rule also explains what lies around the workspace and would pass for clutter: tasks and workflows with inventory names, disabled, carrying the number of the card they served to prove. They aren't leftovers from experimentation. They're the proofs, left in place.

And the loop closes the following night: the agent that tidies the board only archives a card if its thread contains the proof of delivery. The rule has its inspector.

The counterpoint

What the agents don't replace

Everything above could suggest a kind of magic: agents that tidy, write, analyze and deliver while nobody watches. That would be a misreading. None of it exempts you from the ordinary practices of the trade. Tests run, code gets analyzed, dependencies get audited, and the release chain refuses by default.

Four successive barriers, each at a different moment, each able to say no.

1. Before the commit local hooks

   The first net triggers on the machine, before anything leaves: formatting, configuration-file syntax, big files refused, forgotten merge conflicts. And two unforgiving guards — no private keys, no debug statements left in the code.

   • ruff — lint
   • ruff — format
   • mypy
   • yaml / toml / json
   • big files
   • merge conflicts
   • private keys
   • debug traces
2. On every push continuous integration

   On the main branch as on every merge request, seven independent jobs, one of them dedicated to security: static analysis of the code for dangerous patterns, and a dependency audit against known vulnerabilities. A preliminary job detects what changed so only what's affected runs, and the trigger gets read-only rights on the repository.

   • change detection
   • lint & format
   • dead code
   • types
   • security analysis
   • dependency audit
   • tests
   • database concurrency
   • TypeScript on the interface side
3. Before publishing refusal by default

   Building the package first goes through the same series of checks as continuous integration — impossible to produce a deliverable without them. Then two categorical refusals: the published version must match exactly a tag placed on that commit, and the working tree must be clean. One unsaved modification is enough to block.

   • full checks
   • commit == tag
   • clean tree
   • validated package
4. Deployment a written procedure, eleven steps

   Going to production on the home cluster follows a thirty-page runbook that announces its nature up front: "the procedure AND the real traps met in production — not a theory". Read the release log and the migrations before launching anything; deploy the latest tagged version, never the current state of the branch; check disk space; make sure no deployment is already underway; follow the progress without trusting the status alone; rule out the already-known false positives so you don't chase ghosts. The start and the end are announced in Luge, by Luge.

   • log + migrations first
   • latest tag, not the branch
   • disk preflight
   • backup
   • idempotent migrations
   • known false positives
   • start and end announced

The detail that matters, for someone working alone: the local command that checks everything carries the comment "what continuous integration runs". The same control, identical, on the machine and on the server. Discovering a failure ten minutes after pushing, when nobody else can take over, is ten minutes lost for nothing.

But the most instructive part is how the deployment runbook ends. It doesn't claim to cover everything: it closes on three explicit lists — what's already automated and shouldn't be rediscovered; what remains a human judgment and can't honestly be mechanized; and the recommendations from the latest post-mortem, presented as not implemented.

That third list is an admission, written in black and white in the procedure itself. Deciding that a migration needs deferred treatment requires reading a schema drift and reasoning about a dependency — "not a mechanical grep reliable at 100%". Deciding whether to roll back or force forward depends on the actual state observed. Those decisions aren't delegated, and the procedure says why.

An agent can write the ticket, write the fix, prove it works and follow the deployment. It exempts you neither from a chain that says no, nor from a procedure that knows what it doesn't know.

The touchpoints

Where the human takes back the reins

A fleet of autonomous agents is only worth the quality of its interruptions. There are five kinds, and each has a form.

The report with numbered proposals. The nightly agent ends with a direct message: what was archived, reworded, reprioritized, the zombie cards, and its numbered proposals. You answer with the numbers you accept.

Proposal mode. The day plan is composed, then submitted. The agent has the right to prepare everything and apply nothing.

The explicit request. Every outgoing action — sending an email, publishing, writing to someone, booking — goes through a formal request to the human. The prompt says it plainly: never an outgoing action without agreement.

The card proposed by the review agent. The agent that re-reads the code doesn't just comment: what it spots becomes a card proposal, which waits for validation before entering the board. It's the same rule as everywhere else — it prepares the case, it doesn't enter it. A recent review thus produced a run of cards in a row, one of which simply consists of writing the notes that follow from it.

The approval step in a workflow. When a card is assigned to an AI on the main board, an agent does the work — but it is forbidden from marking the card done. An approval step waits for the human; only then does a second agent close the card, or comment on the refusal.

The memory

What the system keeps between two passes

An agent remembers nothing from one run to the next. For a daily automation to do something other than repeat the same thing every day, it needs a place to deposit what it did. That's what tables are: small typed databases, written by a human, an agent or a form alike.

Two of them carry whole pieces of the method.

The detail that matters in the second one: out of seven columns, four fill themselves in. Who answers, when, under what name, at what address — the platform injects them at write time. The form only asks what a machine can't guess. That's the difference between a questionnaire you eventually stop filling in and a three-second gesture you make every morning.

Alongside the tables, the workspace journal gives the other half of the memory. Tables keep facts comparable over time; the journal keeps the unfolding — hour by hour, what actually happened in the day, to re-read in the evening.

• 2 a.m. · 45 actions The highest peak of the day. It's the nightly agent tidying the board — nobody is at the screen.
• 7 a.m. · 32 actions The note review then the plan composition, just before arrival.
• 10 p.m. · 33 actions The evening pickup, the only crest where messages (in blue) weigh as much as the objects created.
• 2 failures Flagged in red on the axis, at noon and around 6 p.m. An automation that breaks says so.

This curve is the best summary of the page. The biggest working hour of the day is two in the morning, and there's nobody to see it go by. The rest reads just as well: the troughs of the night and mid-afternoon, the evening pickup, and two failures that don't hide — because an automation that falls over must announce itself, otherwise you believe it's running.

The loop

Everything seen once is written down

The agents have 89 skills at their disposal. About forty of them don't come from the platform's catalog: they were added over the days by an improvement loop that reads the real conversations, spots the laborious sequences and proposes a shortcut.

You can read the origin in their descriptions. One of them opens like this: "Observation [3] shows a long chain of find_tools, notion-search, and notion-fetch. A dedicated skill can streamline the pattern." The observed pattern, then the proposed remedy — in the description of the remedy itself.

These proposals don't apply themselves when they carry consequences: the ones that fork stay waiting for an explicit human "no", and everything that was applied can be put back to its prior state, with the reason recorded.

It's not an isolated mechanism, it's the same gesture repeated at three altitudes. The review agent records what it sees in the code and turns it into cards. The proof rule records in the command-line client every gap met along the way. The improvement loop records the friction of conversations and turns it into skills. Every time: what was observed once becomes a durable trace, and that trace improves the next tool.

Nothing gets lost along the way. An observation becomes a card, a card becomes a command verb, a friction becomes a skill — and the product advances on everything its use teaches it.

The product's five loops — talk and act, know and remember, materialize the work, automate, improve — then read in the right order. The fifth isn't the last: it's the one that makes the other four cumulative.

The layer underneath

RoomKit, that's where the flexibility comes from

A last word on what makes all of this technically possible, and which shows nowhere in the interface. When Luge receives a link pasted in Telegram, sends a summary to Teams, takes a phone call, transcribes a meeting or holds a voice conversation with interruption, it doesn't do nine separate integrations: it rests on RoomKit, an open-source framework, built by the same person.

RoomKit is an asynchronous Python library that brings all these conversations back to a single object — a "room" — whatever the channel that leads to it. Sixteen built-in channels (SMS, RCS, email, WhatsApp, Messenger, Telegram, Teams, Discord, WebSocket, voice, video, conference…), the model and telephony providers behind them, a full audio pipeline with speech detection and echo cancellation, the ephemeral presence and typing events, swappable storage, and the agent tooling: memory, document search, tool calling, delegation.

That separation isn't cosmetic. It means the conversational layer gets tested, measured and fixed for itself — the ongoing work on its ingestion capacity is the example, driven by measurements and profiles rather than intuitions. It also means that adding a channel to Luge is not a construction site inside Luge.

And because RoomKit is open, the foundation the platform rests on is readable by anyone — which is a fairly direct way of answering the question "what's really under there".

Three readings

Depending on where you're coming from

Read directly off the development board, August 25, 2026. The numbers move every day. Luge rests on RoomKit, an open-source framework — roomkit.live.