Weekly digest

A week of two tracks: agents get real ground truth, runners grow up

The most interesting thing about this week is that Tuist shipped two distinct product stories at once, and on closer look they share the same instinct: stop pretending the surface area is enough, and give the people and tools using Tuist a way to verify what they’re being told.

On the agent side, two drops landed back to back. The first added a search_tuist tool to the hosted MCP endpoint, letting coding agents query Tuist documentation, the ProjectDescription API reference, GitHub releases, the community forum, and issues in a single call, with cited links and optional prerelease filtering (Search Tuist docs and community from your coding agent). The second added an ask_tuist prompt that starts with the same public material but goes further: when an answer depends on current defaults, feature gates, or error handling, the agent can search the source tree, read focused line ranges, and link back to the exact repository revision so the answer stays verifiable (Source-backed answers from coding agents). All source access is read-only and bounded, with hard limits on scanned bytes and explicit reporting of partial results.

Together these two changes describe a position. Documentation alone ages. Even fresh docs miss the subtle behavior that lives in the code. Tuist is betting that an agent working on a Tuist project should be able to read Tuist’s own source as part of its reasoning, not as a fallback when docs run out. The search_tuist tool gives breadth, ask_tuist gives depth, and the explicit citation requirement keeps both honest.

The runners track tells a quieter story with the same shape. Three drops pushed the runner fleet from “a place CI jobs run” toward a real operational platform. Account-level CPU and memory concurrency limits can now be set independently for macOS and Linux, with the Runners dashboard surfacing hourly peaks and red bars for hours when capacity was exhausted (Concurrency limits for Tuist Runners). Running jobs gained a Terminal tab in the dashboard, with a matching tuist runner ssh <job> command for staying in the local terminal when the debugging gets longer (Terminal access for live runner jobs). And account tokens, the kind of thing that previously meant a CLI ritual, can now be generated, scoped to specific projects, and revoked from the dashboard (Manage account tokens from the dashboard).

What links these three is the recognition that runners are shared infrastructure. Once fleets are shared, the questions stop being about individual jobs and start being about fairness, observability, and access control. Concurrency limits answer the first. Terminal access answers the second. Dashboard-managed tokens answer the third. Each one is unglamorous, and that is exactly why it matters.

Underneath both tracks, SwifterPM quietly flipped from opt-in to default for tuist install, replacing per-worktree package copies with a content-addressable store. Warm restores drop to sub-second, multi-worktree workflows stop paying for gigabytes of duplicated checkouts, and the SwiftPM fallback remains available with a single environment variable for any package graph that still trips it up (SwifterPM is now the default for generated projects). It is the kind of change you only notice when it’s not there.

The through-line is verification. Agents get grounded in source, runners get grounded in real telemetry, and the dependency layer stops being a black box. Tuist is increasingly assuming that its users, whether human or model, will want to look closer, and is building the affordances that make looking closer cheap.