Fabr

Fabr turns the todos next to your files into tasks that an agent defines, plans, runs, and checks. Your folders become the workspace, your files hold the state, and you stay in control.

Inspiration

Every one of us keeps two systems that never meet.

The work lives in folders: a code repository, a class, a trip, a kitchen renovation. The todos live in an app that knows nothing about those folders. When AI agents arrived, a third system appeared: a chat window.

Now you copy context out of your files, explain what needs doing, watch a wall of text scroll by, and hope the result matches what you wanted. If the agent makes a mistake, you often have to start over. If it needs an external service, you have even less visibility into what it can access.

We wanted the todo, the files, and the agent in one place. Not another chatbot or task manager, but a way to delegate work from where it already lives, with the human holding the wheel.

What it does

Fabr shows your folders as a tree. Type a title on any folder and press Enter, and you have a todo. It is a Markdown file inside that folder, next to the work itself.

Choose Generate with AI, and a nine-step pipeline takes that one-line reminder toward a checked result.

The agent gathers context from the folder, defines the task, and asks you what is missing. It creates a plan and waits for your approval before execution. Once approved, a tool loop performs the work, and an evaluator with fresh context judges the result against the success assertions you approved.

The local execution tools can read files, list directories, write Markdown, and create folders, within the task's folder boundary.

Every folder displays its agents' progress. You can pause, suspend, complete, cancel, or redo tasks, and edit individual sections until execution starts. Folders on another machine work over SSH without requiring a remote daemon.

Fabr also supports optional integrations for work that extends beyond the filesystem. With explicit approval, it can retrieve research using Bright Data, access document context through Moss, generate and transcribe speech with Cartesia, and run an Apify actor. We also tested sandbox financial-data access through Nessie.

These are not unrestricted powers handed to the agent. Each external action requires its own grant, with the tool, destination, effect, and approval visible in the task record. Without that authorization, execution stays within the local tool set.

How we built it

The core is Rust, handling the folder tree, task-record format, and SSH backend. Remote trees are snapshotted using tar over a multiplexed SSH connection.

A second Rust crate owns the agent's state machine and communicates with the Anthropic Messages API using tool calls. The desktop interface uses Svelte 5 and Tauri 2, hosting the runner in-process without a separate background daemon.

Every task is a Markdown document with YAML frontmatter and five sections. That document is the shared state between the interface, the runner, and the filesystem. You can inspect it, edit it, version it, or review changes with git diff.

Three design decisions shaped the system:

1. The file tree is the spine. Tasks, rules, and knowledge belong to folder paths, with context inherited from parent folders.
2. The outer loop is deterministic code. The model works inside individual steps rather than controlling the entire workflow, so transitions and approval gates can be tested and replayed.
3. Only the orchestrator owns task state. The GUI and agent coordinate through controlled record updates rather than independently overwriting each other.

Sponsor integrations extend this architecture through capability-aware, explicitly approved actions. Provider credentials are optional, and an approved local plan does not implicitly authorize a remote API call. This separation lets Fabr distinguish what an agent wants to do from what the user has actually permitted.

Challenges we ran into

Our first working pipeline was mostly an illusion.

Execute made one model call and blindly ran its requested tools. The model never saw a directory listing before deciding what to write. Evaluate checked exit codes from planner-generated commands against files that sometimes did not exist.

Both passed their tests because the scripted model followed the happy path. The first real API task exposed the problem. Rebuilding execution as a proper tool loop and evaluation as an independent model judgment was the turning point.

Our task records had competing writers.

The GUI and runner could update the same file. On conflict, the handler reused a stale record and overwrote the user's answer. Per-folder locking and three-way merging resolved the race. That merge logic also established an important rule: a human edit takes precedence over a regenerated section.

Agents assumed tools existed when they didn't.

Our planner repeatedly requested Git on a machine without the required capability. We introduced machine-declared capabilities and plan requirements. If a plan needs something the machine cannot provide, the task moves to "needs harness" instead of repeatedly failing.

External integrations introduced a different problem: permission is not the same as capability.

A configured API key should not automatically authorize an agent to use it. We separated provider availability from per-action approval and recorded each grant in the task. An unknown external-call outcome is treated as a failure requiring reconciliation, rather than assumed success.

Accomplishments that we're proud of

We built an end-to-end pipeline, not just an agent demo.

The task schema evolved from version 2 to version 6 in two days, while retaining compatibility with earlier records. A reminder and a delegated task remain the same file. Nothing needs to be copied into a separate agent workspace.

Tasks can be opened, edited, and run across SSH from the desktop app. The same record captures the plan, approvals, execution progress, and evaluation evidence.

We also demonstrated how that architecture supports real integrations:

• Persistent context + Bright Data: One task confirmed the preference "Stay under $100 for internship supplies." A subsequent task recalled it, performed one approved Bright Data search that returned eight hits, and generated desk.md. Because the search did not return prices, the document labeled its prices as estimates. No purchase was made.
• Moss: Listed three indexes and retrieved 75 documents from agent-memory-context, demonstrating retrieval from an external document store.
• Cartesia: Generated speech.wav and transcribed test audio. The record sheet also supports selecting or recording audio and playing generated speech after a successful approved run.
• Apify: Executed the apify~hello-world actor and retrieved a dataset item.
• Nessie: Exercised sandbox account access, with zero accounts returned.

We additionally discovered five private account tools through Fo, without executing them. Visa, Figma, Microsoft, and Atlassian Forge were not integrated, and sponsor-track eligibility remains unverified.

The accomplishment is not that every sponsor API became a feature. It is that Fabr has a repeatable model for connecting external capabilities to a task while preserving explicit approval, visible evidence, and controlled execution.

What we learned

Green tests on a scripted model prove the plumbing, not the product. The first real task found failures that more than two hundred tests missed.

We learned to separate the work an agent proposes from the actions a system permits, and to distinguish a successful API response from a verified user outcome. Eight research results are not eight verified prices. A sandbox response is not a real financial transaction.

Keeping the outer loop deterministic made failures explainable through the task's log instead of disappearing into a chat transcript.

We also learned that the demo persona matters. We rebuilt the sample workspace twice until it resembled folders someone might actually have on their laptop. The clearest demonstration of Fabr is not a complicated prompt. It is an ordinary todo becoming completed, inspectable work without losing its context.

What's next for FABR: The Fabric

The next step is moving execution into an isolated sandbox with a coding harness and a fixed tool set. The approved plan and gathered context become the handoff, so the agent can perform more complex work without unrestricted access to the host machine.

Three additional capabilities are designed but not yet built:

• Learning from answers: Generalizing the demonstrated preference-recall flow so users don't repeatedly explain the same constraints.
• Telegram integration: Handling short clarification and approval decisions without returning to the desktop.
• A personal data bank: A controlled store for sensitive information, with access mediated through narrowly scoped operations rather than unrestricted agent reads.

The goal stays the same: your work already has a home. Your agent should work there too, under your control.

Built With

• anthropic
• cargo
• claude
• github-actions
• love
• markdown
• rust
• ssh
• svelte
• tauri
• toml
• typescript
• vite
• vitest
• yaml