3webs Visibility Engine
Almost every company asks one commercial question:
“What products and services do we sell?”
There is a second question, and almost nobody asks it:
“What does our company already know how to do internally that would have economic value to someone else?”
Verifying a registration number. Validating a document set. Pricing a job. A compliance check you already run every month, for yourself. None of these are line items in a catalogue. They are capabilities — and until now there was no practical way to sell them separately.
Agent-to-Agent is the mechanism that makes them sellable. But before that becomes visible, one confusion has to go.
Splitting “external A2A” from “internal A2A” is useful when explaining. It should not be presented as two different technologies. It is one paradigm.
Do not confuse the place where A2A is used with the nature of A2A.
An agent can request, use or coordinate the services of one or many agents. And the relationship is symmetric.
“Internal” and “external” describe context and access policy, not the paradigm.
Say the company runs a service:
Registration number + documents + period
Tax report
The same service can be requested by:
Client Agent → TaxCheck Agent
CEO Agent → TaxCheck Agent
Accounting Agent → TaxCheck Agent
Audit Agent → TaxCheck AgentYou do not build four different services. You have one A2A capability, and you decide who may use it, for what, and under which conditions.
TaxCheck Agent may itself need other capabilities:
Client Agent
↓
TaxCheck Agent
├──→ Document Agent
├──→ Fiscal Data Agent
├──→ Verification Agent
└──→ Billing AgentSo we have 1 agent → N agents — and each of those agents can in turn request services from others.
This is why A2A should not be pictured as Agent A → Agent B, but as a network, Agent ↔ Agents, in which provider and consumer roles are not fixed.
Today: Agent A → requests B's service
Tomorrow: Agent B → requests A's service
Or: Agent A → B + C + D, while C → E + FYou do not build “an agent for the outside” and then “an agent for the inside”.
Then you define: who can discover them → who can request them → who executes them → what data they may use → which actions are permitted → what requires authorisation → what it costs → what result it produces.
The company boundary becomes an access rule, not a limit of the A2A architecture.
Agent-to-Agents = a symmetric 1:N relationship
An agent can discover N agents → request N services → combine N results → produce a new service → and become a provider to other agents in turn.
And the very same capability can be used:
internal → internal
external → internal
internal → external
external → externaldepending on identity, authorisation and company policy.
So the right question is not:
“Is this agent internal or external?”
The question is:
“What capability does it offer, who is allowed to use it, and under what conditions?”
That is the real A2A paradigm: not two worlds, internal and external, but one Agent-to-Agents network, 1:N, where the same capability can be both consumed and offered on either side of the organisational boundary.
One wrong conclusion needs heading off. Not building two agents does not make opening outward free.
The same capability, exposed on an external lane, requires things the internal lane does not:
These are not different agents. They are policy layers over the same capability. The architecture stays single; the effort and the liability do not.
This is why price does not attach to a capability. It attaches to a lane. The same capability can be free internally and charged externally without becoming two things.
The argument above would be cheap if this site did not run it. It does.
3webs offers one capability: observe a public domain across the human web, the AI web and the machine web, and return the evidence. That capability is reachable two ways.
A person → form on this site → POST /audit
An agent → A2A JSON-RPC 2.0 → POST /a2a (skill: obs_one_shot)Both requests land on the same execution path. The same evidence is gathered from the target, the same signals are evaluated against the same catalogue, the same action plan is derived. The observation does not change because the requester is a person rather than an agent. What changes is the envelope: a rendered report on one side, a structured data part on the other.
That is the whole thesis, running in production. Not „a human product and an agent product". One capability, two request surfaces — and the boundary between them is a policy decision, not an architectural one.
An agent can also call obs_catalogue for the full signal catalogue, obs_explain for the verdict and evidence on a single signal, and obs_diff to compare a target against a retained baseline. A person cannot: those lanes exist only on the agent surface. Same capability family, different policy.
This essay is a companion piece to The Three Webs: AI Delivery Infrastructure for the Emerging Machine Web by Dan Ionescu — on the split between the Human Web, the AI Web and the Machine Web, and on what a company has to publish to exist in the third one.
This node's capabilities are declared machine-readable in services.json, capabilities.json and agent-card.json. Each capability declares its access lanes separately, with permitted requesters, data scope, human authorisation threshold and its own commercial terms. Lane matrix: allow-lane-matrix.json.
AIVENTURE S.R.L.
București, Sectorul 1
Drumul Pădurea Pustnicu, Nr. 141C
Corp A, Etaj 2, Ap. 5 · Romania, EU
CUI 51415878 · J2025016406000
EUID ROONRC.J2025016406000
CAEN 6210 · Registered 07.03.2025
© 2026 AIVENTURE S.R.L. · 3webs is a trademark of AIVENTURE S.R.L.
Reports are technical observations, not certifications or legal opinions.