What a coding agent needs beyond a model
A coding agent connects a conversation to actions. The model can ask to read a file, change some code, or execute a program. The application has to decide how each request is handled.
Tools need a clear boundary
In the Workbench project, every file-tool path is resolved against the selected workspace. Resolving symlinks matters: a path that appears to be inside the project can point somewhere else.
That protects the file-tool boundary. It does not turn a Python subprocess into an operating-system sandbox, so execution still requires care about the workspace and code involved.
Errors belong in the conversation
A malformed tool argument should become an understandable tool result. Crashing the program loses the conversation and gives the model no chance to adjust.
The agent loop also has a step limit, request timeouts, and an explicit read-only mode. These are small controls that make a run easier to inspect.
Verification closes the loop
An edit is a proposal until it has been checked. The final response should distinguish between files changed, tests actually run, and anything left uncertain.
The project tests the conversation loop with simulated provider responses. That verifies the local behavior without assuming an external provider is available.