If your agent is reasoning across service boundaries you should be giving it whatever you'd normally use when you reason across service boundaries, whether that's an openapi spec or documentation or a client library or anything else. I don't see it as any different than a human reasoning across service boundaries. If it's too hard for your human to do that, or there isn't any actual structured/reusable way for human developers to do that, that's more a problem with how you're doing microservices/developing in general.

> they have to do language translation on the fly in the generation, which is going to degrade attention 100%,

I'm not completely sure what you're alluding to but if you don't have an existing client for your target service, microservices/developers going to have to do that anyway because they're serializing data to call one microservice from another. The only exception would be if you starting calling the other application's code directly from the other's in which case again you're doing microservices wrong or shouldn't even be doing microservices at all (or a lead engineer/other developers deliberately wanted to prevent you from directly integrating those two applciations outside of the API layer and it's WAI).

None of these seem like "microservices are bad for agents" problems to me, just "what I'm doing was already not a good fit for microservices/I should just not do microservices anymore". Forcing integration against service boundaries that are independently built/managed is almost the entire point as far as I'm concerned

Think of it like this. If you're multilingual but I ask you a hard question with sections in different languages, it's still going to tax you to solve the problem over having the question be asked in one language.

If you codegen client wrappers from your specs that can help, but if something doesn't work predictably the indirection makes debugging harder (both just from a "cognitive" standpoint and from inability to directly debug a unified system).

I prefer FaaS + shared libraries over microservices when I have to part things out, because it gives you the independence and isolation of microservices, but you're still sharing code across teams and working with a unified stack.