Ah OK, so the ACP connector ensures tool calls work with Zed, and communicates the available tools and their results to the harness, and then the harness mainly provides a system prompt and the API calls?
Harness does a lot of things potentially, but this depends on the harness.
1. Manages what is loaded in the context (I.e. sent to the model), this can be about compaction, summarization, removing things it judges no longer relevant, proving memory
2. Handling retries and how to resend data , lot of model specific behavior here
3. Wires up tools like web search or lsp servers
4. Skills and how to use them
5. Plugins/sdks
6. Management of rules (AGENTS.md)
About everything interesting really, a ton of work goes into this and getting it right is surprisingly hard
No, not especially, the client (Zed in this case) can add some things (like @ing a file or class) and hint stuff but in all seriousness the harness is doing the things I’ve mentioned
You can see it from the different transcripts from the different tooling harnesses (´agents’ in agent client protocol speak) you can also just read the source for pi or zed or anything here don’t take my word for it.
You will see different web search from pi and codex, different tool calls, different context compaction strategies, etc.
The client has some control over this stuff but very little, like zed can pass in mcp servers to use or files to add to the context but the tooling harnesses can ignore those requests
1. Manages what is loaded in the context (I.e. sent to the model), this can be about compaction, summarization, removing things it judges no longer relevant, proving memory 2. Handling retries and how to resend data , lot of model specific behavior here 3. Wires up tools like web search or lsp servers 4. Skills and how to use them 5. Plugins/sdks 6. Management of rules (AGENTS.md)
About everything interesting really, a ton of work goes into this and getting it right is surprisingly hard