After building the multica + brains symbiotic system, I started asking the reverse question: how should Agent applications call one another? Each of them already has Agent modules and can use Agent capability internally. At the same time, I also want them to connect to each other, and even be managed in a unified way by a front-end Agent such as openclaw. Once you move in that direction, standardizing call relationships — and constraining, planning, and designing the boundaries of large and small Agent capabilities — becomes a real problem.

In the past, microservices and complex systems already gave us a relatively mature interconnection pattern: the Service Provider exposes OpenAPI, the Service Client makes the calls, and then stitches multiple interfaces into a business flow. That pattern works well, but it lacks business semantics. The caller still has to write a lot of custom logic.

If we leave the API with the Provider, put business rules into Skills, and let Agents act as Clients, service-to-service calls may start to look different.

In the traditional pattern, the problem is not the API itself

The classic pattern is clear: the Service Provider exposes OpenAPI, the Service Client generates or writes call code based on that interface definition, then combines multiple interfaces into a business flow. There is nothing wrong with that model. What it solves is standardized invocation.

But the gap is equally clear: an API defines a capability boundary. It does not define business rules. Even HATEOAS or GraphQL are better at resource access and query expression than at directly carrying rules like this: when the order amount is below 100, check inventory first, then recommend an item that works well as an impulse add-on.

Of course, that logic could always be implemented before. It just usually required a lot of custom code to stitch together multiple APIs, business rules, exception handling, and flow decisions.

Agents let the caller work with business rules

Since Agents appeared, I have increasingly felt that application interconnection may gain a new implementation style:

• The Provider continues to expose APIs
• Skills add business rules, user use cases, the business relationship between multiple APIs, and invocation strategy
• Agents act as the calling side, load those skills, then understand and invoke the capabilities

In rough terms, you can think of it like this:

OpenAPI ≈ Skill + API

I am not trying to replace OpenAPI. The point is closer to this: traditional OpenAPI mainly answers “can it be called,” while Skills add “how should it be called in a business context.”

What a Skill can contain is not just interface descriptions. It can also include:

• user use cases
• the business meaning of one or more APIs and the relationship between them
• business-level calling rules
• technical exception-handling strategies

That means the Service Provider may barely need to change. The side that changes most is actually the Client. A large amount of integration logic that used to live in code may move into Prompt + Skill driven invocation and orchestration.

Two modes: Choreography and Orchestration

I think this can be understood through two different modes: Choreography and Orchestration.

In Choreography, there is no central orchestrator. Each application or service still collaborates like a microservice system, but the Service Client is no longer just hard-coded logic. Instead, Agent + Skill can take over that role, so the invocation becomes more semantic and more business-oriented.

In Orchestration, I find the picture even more interesting: the central coordinator could be implemented entirely by an Agent. In other words, a Supervisor Agent can take the necessary context, then autonomously call multiple applications and services to complete integration flows that used to require a large amount of Client-side code.

Calling this “zero-code development” would obviously be exaggerated. A more accurate way to say it is: once the Service Provider already exposes standard APIs, the customized integration code on the Client side may be significantly reduced or partially replaced by Agent + Skill.

This is the framing I currently prefer

This is still an early personal idea, but I increasingly prefer to look at it this way: an Agent is not just an intelligent module added to an existing application. It may also become the next generation of Service Client.

If that direction holds, then in the future what applications expose to one another may not be only interfaces, but also capabilities and business rules.

Needs Verification

• The minimal reusable structure of a Skill still needs more practical validation.
• We need clearer boundaries for which client-side integration logic is suitable to be replaced by Agents and which parts should still remain in code.
• The reliability, auditability, and failure-handling model of a Supervisor Agent in real production scenarios still need more samples.