Block's Berd makes a duller argument than its mascots: show the agent's context as product state

Block has open-sourced Berd, the desktop application its teams use to work with AI agents across projects, skills, tools and models, in a release dated August 18 by a dev.to writeup ^[1]. The app itself matters less than the line in its own product document: a user should be able to tell where they are, what context is active, which model or agent is responding, and what operational state the system is in ^[6].

That reads like UI housekeeping. It is actually a state-design position, and it comes out of a specific mess. Block says Berd grew from a fragmented internal experience, with teams reaching agents through goose, Claude Code, Codex and other tools, each of which handled configuration and context differently ^[2]. The fix was not another chat surface. Berd arranges conversations, files, folders, instructions, agents, skills and models around persistent projects ^[3], which is a different primitive from the thread. Threads accumulate; projects are meant to be returned to.

The architecture keeps that honest. The repository describes a Tauri 2 and React 19 desktop app that connects to the Goose backend over the Agent Client Protocol ^[4], with the desktop side owning projects, sessions, context and configuration while the backend owns the agent loop ^[5]. Put the context store on the side the user can see and click, and leave the model turn to the process that runs it. If context lives only inside the loop, the only way to audit it is to read the transcript and guess.

The reason to care is reproducibility. The dev.to piece lists the things besides the prompt that shape an agent's next action: the repository it opened, the files and folders attached to the session, persistent instructions or project rules, the selected agent and model, enabled skills and tools, permissions and approval boundaries, prior conversation state, environment variables and local services, and the tests or evidence it can actually run ^[7]. That is nine variables around one visible input ^[12]. When they are invisible, the same question in a fresh conversation returns a different answer and a model switch silently drops tools ^[8]. Model and agent changes can also move tool access, speed, cost, reasoning behaviour and output format ^[10], none of which a calm chat window signals.

The author's mitigation for people not shipping their own agent shell is a seven-line context card written before any large task: the exact workspace, repository or branch; one outcome for the session; the specific files, screenshots, requirements or schemas allowed to influence the work; the responding agent and model; and the active skills, tools and approval boundaries ^[9]. The attachment discipline is the part operators get wrong: more context is not automatically better context, and a short list makes contradictions easier to spot ^[11].

Three things to watch. Whether the shipped interface actually surfaces the four states the product document promises, or displays a project name and calls it context ^[6]. Whether the Agent Client Protocol boundary is real enough that a second backend can sit behind the same desktop state ^[4][5]. And whether the active context set can be exported and diffed rather than merely viewed, because a variable you cannot compare across two runs is still not evidence ^[7]. Note also that the design intent described here comes from one secondhand writeup of Block's documents ^[6], not from Block's own public statement.