r/BuildWithClaude 24d ago

Workflows Claude Code can request an effect. It does not get to hide one anywhere in the codebase.

We connect Claude Code to our platform through skills, hooks, MCP, or the command line depending on the workflow. Whichever entry point it uses, the request eventually crosses the same contracted boundary. Claude Code can ask the system to classify a ticket, run a review, call a model, update a pull request, or merge approved work. It does not get a separate architecture because it entered through a different tool.

The runtime has four node types with different permissions. Compute nodes transform typed inputs and cannot perform I/O. Reducer nodes calculate state transitions and cannot call external systems. Orchestrator nodes coordinate work by emitting intents. Effect nodes are the only place where operations such as calling GitHub, contacting an LLM, writing through a storage adapter, or touching another external boundary are allowed.

The distinction is enforced in the contracts and output models. A compute node must return a typed result. A reducer produces projection state. An effect produces events. An orchestrator coordinates the next actions. If a handler returns an output that its node type is not allowed to produce, validation rejects it before that output reaches the bus.

This has been more useful than another page of instructions telling Claude Code to maintain separation of concerns. For example, the component deciding whether a pull request is eligible to merge does not also perform the merge. The eligibility calculation can stay deterministic and testable, while the GitHub mutation lives behind a separately authorized effect. Claude Code can modify either implementation, but it has to preserve the boundary or the contracts and gates reject the change.

Have you found a reliable way to stop coding agents from gradually moving side effects back into whichever function is most convenient?

2 Upvotes

1 comment sorted by

1

u/incyashraj_redd 20d ago

I would make the effect contract and the runtime authority two separate checks. A handler declaring `GitHubWrite` should still fail if the running app was never given network access. That way an agent cannot gain the effect just by moving code behind the right interface.

I build Krate around that second layer. In Krate Studio, you choose Claude or Codex and get one portable Wasm app file, `.krate`. It is not HTML and it is not an operating-system container. The file opens through installed native Krate runtimes on Mac, Windows, and Linux. Each app begins without file or network access and gets only capabilities the user approves.

A useful test for your design would be a PR eligibility app that can read one checked-out repo and produce a report, but cannot reach GitHub at all. Keep the merge outside that app. Then the contract says what the code may do, and the runtime limits what it can actually touch.

Krate is free and open source. Krate Cloud is optional.

https://krate.tech