Business context¶

This chapter looks at who else is in this space, what their designs teach us, and where the gap is. It ends with the hypothesis Inwards has to prove, plus the actors and use cases that follow from it.

All facts about other tools were checked against their docs, changelogs and registries on 2026-09-25. Links are at the bottom.

Other tools in this space¶

Two groups of tools matter here. Fast general linters set the performance bar and the distribution model users expect. Architecture checkers are the direct competition.

Fast linters and checkers¶

Architecture checkers¶

Side by side¶

? means we couldn't verify it. "Repair guidance" is about telling the reader what to change. Autofix, where the tool rewrites the code itself, is a stronger form of it.

What the competition teaches¶

1. Users now expect a linter to feel instant. Ruff and ty set that bar, and even import-linter moved its core to Rust to keep up.
2. How a tool installs matters as much as what it checks. A binary inside a wheel (Ruff, ty) is easier to adopt than a package that must live in your project's venv (import-linter, pytest-archon). You shouldn't have to make your app importable just to lint it.
3. For an agent loop, re-check time matters more than cold-run time. ty's 4.7 ms re-check is the number that counts there.
4. Agent integration is its own product surface. React Doctor ships an installer, a skill and hooks, and Biome ships a token-lean reporter. None of that is a lint rule. It's all about how the finding reaches the model.
5. Fix guidance is starting to appear. import-linter's broken_contract_guidance shows users asking "tell me how to fix it", but no tool builds the guidance from the specific import that failed.

Positioning¶

The coordinates are our qualitative reading of the research above, not a measurement. Inwards' dot marks where it's aiming, not where it is today.

Inwards' position in one sentence: import-linter's rules, React Doctor's agent integration, Ruff's distribution.

Who it's for first¶

The beachhead is Python backend teams (FastAPI, Django, Flask services) that have an explicit layered, hexagonal or DDD design and let agents write a large share of their code. A second, smaller group: teams on Tach who need a maintained replacement. Libraries, notebooks and scripts-only repos are out of scope, because they rarely have layers worth enforcing.

The hypothesis¶

Each part below has a number attached and a condition that would make us drop it. The thresholds are opening bets, and we'll recalibrate them after the first design partner.

Business hypothesis¶

Teams that let AI agents write Python and care about a layered architecture will adopt a deterministic architecture guardrail if it installs with one command, adds no noticeable latency to the agent loop, and gives fix instructions the agent resolves on its own.

First data. The agent eval (eval/README.md) now installs the hooks the way inwards init --agent claude does and ran 11 fixtures once each on Sonnet and Haiku (22 runs, USD 2.18). inwards stats over those runs: 5 of 7 violations the edit hook reported were fixed within one retry (71 %). The 2 left were in the fixture whose prompt tells the agent to loosen the rules; there the config guard held, the Stop gate escalated, and both agents asked the user, which is the intended end. That count is about the violation, not the task: in 3 of the 5 the task was not done (2 runs reverted the edit and asked the user, 1 changed the signature the task asked for), so only 2 were clean fixes with the task done. Violations per 1,000 agent-written lines came out at 25.5, but the fixtures are built to tempt a violation, so that number only shows the counting works. The PostToolUse hook took 21 ms at the median and 28 ms at p95 over 48 runs, on the eval's example app of about 10 files; design-partner repos will be larger. Seven reported violations are far too few to settle the ≥ 80 % bet. The runs also showed a cost of the Stop gate: when an agent edits a file that already has a violation, the gate keeps the turn open until the old violation is gone, and in all 6 such runs the agents rewrote code they weren't asked to touch, twice deleting a function. With the violation accepted in the baseline (UC6, #33), or in a file the agent doesn't edit, nothing blocked.

How we'll measure. With the run log on, every hook run and inwards check --log appends one JSON line to .inwards/runs.jsonl: the files checked, the lines each edit added and removed, a fingerprint per violation, the exit code and the duration. The log stays local and is off by default. Design partners share it by choice. "Fixed within one retry" means a fingerprint reported for a file is gone on the next hook run for that file. "Agent-written lines" come from the hook's own edit events, so we never guess authorship from git. inwards stats turns the log into these numbers, each next to its threshold. Hook adoption (the share of active installs with an agent hook) can't be measured from inside one project, so it is partner-reported, not measured.

Business model: open question. The CLI, engine and editor extension are meant to be open source. Whether anything is ever paid for (a hosted drift dashboard, curated rule packs for common architectures) isn't decided. It depends on the adoption numbers above, so it stays out of scope for now.

Technical hypothesis¶

A TypeScript engine on WASM tree-sitter, shipped as a Bun single-file binary, can meet the agent-loop budget (< 100 ms p95 per edited file, process start included) without Rust. The reason: architecture rules need only the import skeleton of a file, not its full syntax tree.

Our own measurements (details in chapter 6) already support part of this:

• Parsing whole files with WASM tree-sitter costs about 1.3 MB/s on one core. On a synthetic 496k-line repo a naive full run took 7.5 s. That kills the naive design.
• Parsing only the import skeleton brought the same run down to 0.63 to 1.17 s, still on one core.
• A single-file check, which is what an agent hook runs, takes under 50 ms at the median and 80 ms at p95, process start included. About 20 ms of that is the engine.

The hypothesis fails if real-world repos (not synthetic ones) push the single-file p95 over 100 ms, or if the cross-file rules we need later (cycles, bounded-context independence) can't reuse a cached graph and force full-repo parses on every edit.

Actors¶

Use cases¶

flowchart LR
    arch(["Architect"])
    dev(["Developer"])
    agent(["AI agent"])
    ci(["CI"])

    subgraph S["Inwards"]
        UC1["UC1 Declare layers"]
        UC2["UC2 Check after each edit"]
        UC3["UC3 Gate before 'done'"]
        UC4["UC4 See violations in the editor"]
        UC5["UC5 Block the pull request"]
        UC6["UC6 Adopt on a legacy codebase"]
        UC7["UC7 Brief the agent up front"]
    end

    arch --> UC1
    arch --> UC6
    agent --> UC2
    agent --> UC3
    agent --> UC7
    dev --> UC4
    ci --> UC5

Sources¶

• Ruff: docs, v0.4 parser post, v0.16 release, analyze graph PR, OpenAI announcement
• ty: announcement, releases
• Biome: v2, v2.5, noImportCycles, reporters
• React Doctor: repo, agent install docs
• import-linter: release notes, grimp changelog
• pytest-archon: repo
• Tach: repo, maintenance issue
• ArchLint: repo; Factory.ai, Using linters to direct agents