I never quite understood why agents should be treated as anything but normal software engineering. "Just" build a normal service and add an async call to some agentic framework, then parse the results. There is no need to "flip" this system and have the agent BE the process and invent a whole new ecosystem to manage the complexity that this flip creates.
If an agent is treated like nothing but a call to an external service (...which it is), everything fits in the existing programming paradigms. But I guess that's not very exciting. Only pragmatic.
AI for proofreading/spelling correction and reordering works quite well. My words, but perhaps structured in a way which makes more sense, with sentiment replaced by synonyms.
Basically an automatic "second-pass" which I would've caught had I re-read it, but automatically.
I've taken to sandboxing my entire agent in a Docker container. I wrote a tool that pretends to be an ACP client but is actually making Docker containers, copying files I specified in, bind-mounting, etc, and then proxying ACP via websocket to an agent in the container (except the ACP terminal/FS commands, those happen in the container).
It works well, though there is some leakiness around paths. I opted to make it place/mount files at the same path as on the host so paths are the same (as opposed to manipulating the ACP messages to modify paths on the fly, that felt messy and buggy).
Configurable networking is on my list for the future, but I haven't decided whether to start with IP-level firewalls or if it's better to start with a proxy and firewall rules to force traffic to it. IP firewalls suck for APIs that might have semi-dynamic IPs.
Well, speak for yourself. My MCP servers are pretty solid.
There's nothing in the protocol making them inherently poor other than perhaps popularity, causing a swarm of people vibe-coding things they don't understand.
Isn't much of this made redundant by being part of an existing system? Also, this level of detail is a recipe for being outdated once the issues and compromises starts coming in
> Isn't much of this made redundant by being part of an existing system?
I haven't found that to be true in my work. If you're only making a minor change to an existing system, then you may not need a design doc, but a significant change to an existing system has as much, if not more, complexity and ambiguity than greenfield development.
> Also, this level of detail is a recipe for being outdated once the issues, compromises and compromises starts coming in
I think this is what people typically get wrong about design docs.
I don't think design docs are a good medium for being the perpetual, living description of the system. I think design docs should capture the design at the time of implementation. You should modify the design docs while you implement the work called for in the design document, but once you're done with that work, you freeze the document and preserve it for posterity only.
The design doc is about a specific change to the system. If you need a doc to describe the high-level architecture of the system as it evolves, that should be a different doc.
We don't know how much they are bleeding financially, it might just be a front
reply