# A polyglot automation kernel for humans and agents.

> Fabrik sits between your team, their agents, and the infrastructure that runs their code. Cache hits, remote runners, toolchains, all behind one graph.

Open source · MIT licensed · [Built by the Tuist team](https://tuist.dev)

- [Read the docs](https://fabrik.run/guide/what-is-fabrik)
- [View on GitHub](https://github.com/tuist/fabrik)


```sh
$ fabrik init
→ wrote `fabrik.toml`

$ fabrik build app/hello
→ cache hit · 2 of 3 actions restored
→ built `app/hello` in 84ms
```

## Why we built Fabrik.

### The world we built for

The tools most teams reach for to build, test, and run their code grew up around one particular user: a human developer at a terminal, running a command a few dozen times a day, skimming the output, and forming a mental model of the project from what scrolls past. Every choice these tools make is calibrated for that user. Verbose logs. Approximate errors. Implicit toolchains. Ergonomics tuned for one language at a time.

### What changed

The shape of the work has shifted. Coding agents now sit alongside humans in the same repo. They iterate faster, run many attempts in parallel, and unlike humans, they cannot skim. A two-gigabyte log is not signal to an agent; it is a wall. They need the system that runs their work to talk back in structures they can query, not paragraphs they have to parse.

The economics shift too. One developer running their build, test, and dev commands forty times a day is comfortable on a local cache. The same developer with two agents working alongside is not. Cache hit rates that felt fine for one person collapse the moment several attempts share most of their inputs but each re-run from scratch. Shared, content-addressed caching and the ability to offload work to remote runners stop being optimizations and become the price of doing the work at all.

### Where the seams show

Today's tools were not built with this in mind, and the seams show. Diagnostics are written for a human reader, not a machine consumer. The dependency graph is implicit, locked inside the tool's head, instead of something you can ask questions of. Reproducibility is best-effort, which is fine when you trust your own laptop and uncomfortable when an agent claims a run passed on a machine you cannot see. Per-language tools fragment exactly when cross-language pull requests are getting more common, not less.

### What Fabrik does differently

Fabrik is an automation kernel. It sits between humans, coding agents, and the execution infrastructure beneath them: local cache, remote runners, and the toolchains they invoke. Every action is content-addressed, with a declared input digest and a deterministic environment, so a cache hit on your laptop, in CI, and on a remote runner all mean the same thing. Diagnostics are structured. The graph is queryable. Targets across languages share one declaration model. The result is a substrate that gets out of a developer's way and gives an agent something to reason about.

## One graph for every kind of work.

Scripts and first-class language targets share the same content-addressed graph, so useful work can be skipped or distributed without changing how teams describe it.

### Scripts

- **Scripts**: Any shell command can become a content-addressed action. Declare argv, inputs, outputs, env, and resource needs; replays are cache hits.


### Languages

- **Rust · WIP** (Resolve, Build, Test): Per-crate targets for binaries, libraries, tests, and proc macros. Dependency resolution, compilation, and tests, all cached.
- **Swift · WIP** (Resolve, Build, Test): Apple platform targets for iOS and macOS, including simulator-aware runtimes for agents to launch, log, and inspect apps.
- **Elixir · WIP** (Resolve, Build, Test): First-class Elixir and Erlang on a pinned OTP pair. Mix-free per-module compilation under one cached graph.
- **Add a language**: The target model is open. Propose or contribute a new language frontend on GitHub. Contribute on GitHub →

## Declare targets, build the graph.

A fabrik.toml file declares targets in plain, structured form. Fabrik turns them into a content-addressed action graph that both humans and agents can inspect.

- Per-package fabrik.toml, one per directory.
- Cache lives in .fabrik/ at the workspace root. Gitignored.
- A one-line edit in a leaf crate invalidates only that crate and its reverse deps.


Example `app/fabrik.toml`:

```toml
[[rust.library]]
name = "greeter"
srcs = ["src/lib.rs"]

[[rust.binary]]
name = "hello"
srcs = ["src/main.rs"]
deps = ["greeter"]

[[rust.test]]
name = "greeter_test"
srcs = ["tests/greeter.rs"]
crate_root = "tests/greeter.rs"
deps = ["greeter"]
```

## Questions, answered.

### Is Fabrik production-ready?

Fabrik is early. The Rust support is active, scripts are becoming first-class cached actions, and the remaining work is mostly around build-script support and per-target feature resolution.

### Does it replace your native toolchain?

No. Fabrik gives existing automation a graph, cache, and execution contract. Teams can start with scripts, then move language-specific work into granular targets as the support they need lands.

### Why is this agent-native?

Agents get the same APIs humans get: structured diagnostics, causality queries, and inspectable cache. The build is no longer a black box for the tool writing your code.

### How is caching different?

Every action is keyed by a content-addressed digest of its inputs and environment. The same digest hits locally, in CI, or on a remote build farm.

## Ready to try Fabrik?

Install with mise, run fabrik init, and start declaring targets.

- [Read the docs](https://fabrik.run/guide/what-is-fabrik)
- [Star on GitHub](https://github.com/tuist/fabrik)