Clients
Software that can ask for a goal instead of calling only one fixed endpoint.
Give software a way to ask: who can help me achieve this?IICP is an intent, capability and trust layer for networked execution.
The web can find pages. APIs can call services you already know. But future software needs something more: a way to find the right helper for a goal, compare whether it can be trusted, and then use it without being trapped in one platform.
The existing internet is strong at addressing, transport and access. IICP explores the next functional layer: purpose-aware coordination across clients, directories and execution-capable nodes, with trust signals that can become inspectable instead of private platform magic.
IICP is currently an unfunded, non-commercial research project maintained by one private steward seeking co-stewards. It publishes open specifications and reference code; this website is not a hosted AI or commercial service.
First-glance idea
IICP wants the internet to help software find the right capability, not only the right address.
What are we building?
Three simple parts: software that asks by goal, helpers that can do useful work, and shared evidence that helps choose between them.
Nodes
Helpers that declare what they can do and return useful work.
Directory and evidence
A shared place to find nodes, compare signals, and make better choices.
Why support this?
- From fixed vendor to open choice: Instead of being tied to one preselected service, a client can look for the helper that fits the task now.
- From blind trust to visible signals: The choice should be based on evidence such as reachability, version, behaviour and declared rules, not only on brand promises.
- From one giant app to many helpers: Large goals can be solved by combining specialized tools and nodes, while the client keeps control of the decision.
The deeper goal is freedom of movement: join, leave, choose another helper, or use another implementation without asking one gatekeeper.
Honest status
IICP is live, but still early. The promise is not that everything is solved today. The point is to build and test the open foundation before this coordination layer becomes locked into someone else’s platform.
Expert thesis
Addressability solved “where”. IICP is about “who can satisfy this intent, under which evidence and constraints?”
DNS, IP, URLs, APIs and SDKs make networked systems reachable, but they do not by themselves express purpose. A client that needs an outcome still has to know which provider to call, how to judge it, what fallback exists, and whether the provider’s claims are credible.
IICP treats that missing coordination as protocol work. The goal is not another hosted AI app. The goal is a substrate where clients can express intent, nodes can declare capabilities, directories can evaluate evidence, and execution can remain distributed.
Philosophically, this shifts the internet from endpoint-centric integration toward purpose-aware cooperation. Technically, it requires strong restraint: the control plane must help resolve work without capturing execution, trust, governance or all payloads into one authority.
The four protocol-facing primitives
Intent
A request should be expressible as a desired outcome plus constraints, not only as a preselected host, SDK account or URL.
Capability
Providers should declare what they can do in a way that clients and directories can compare across heterogeneous runtimes and implementations.
Evidence
Selection should use observable signals: health, conformance, versions, signed events, policy declarations, reputation and receipts.
Resolution
A directory should help resolve candidate providers without becoming the owner of task payloads or the universal executor of the network.
Foundation before final taxonomy
The final map of intents does not have to be perfect before the substrate exists. The ontology of tasks, the quality grading of results, the feedback loops around success and failure, and the semantic categories used by the mesh should mature through real use.
That is why conformance, capability declaration, versioned specifications, scoring rules and clear responsibility boundaries matter now. They are not bureaucracy around the vision; they are the conditions that allow future semantic depth to evolve without turning into ambiguity, fragmentation or hidden central control.
Old model vs. IICP model
Old model
Applications are wired to known APIs, vendor accounts and private dashboards. The integration decides the future path before the actual need appears.
IICP model
Applications can start from an intent and resolve a suitable provider when the need appears.
Consequence
Provider choice can change with health, model class, policy, latency, cost, quality and local user preference.
Old model
Discovery, ranking, execution and trust often collapse into one platform boundary.
IICP model
Discovery, execution and evidence can remain separate planes with different responsibilities.
Consequence
Coordination can become shared infrastructure instead of another central chokepoint.
Old model
Trust is commonly delegated to brand, contracts, private scores or vague claims.
IICP model
Trust can be built from accumulated, inspectable behaviour and protocol-visible evidence.
Consequence
A small reliable operator can become discoverable, and a large provider still has to prove quality.
Old model
Complex workflows are glued together manually and become fragile when one service changes.
IICP model
A larger goal can be decomposed into capability requests, each selected and verified under current conditions.
Consequence
The network can support adaptive problem solving without turning everything into one mega-application.
Architectural invariants
These constraints keep IICP from becoming a centralized platform wearing protocol language.
The directory is a resolver, not a ruler
It can evaluate metadata, compliance, health and reputation, but it should not become the mandatory processor of every payload or the owner of every relationship.
The client keeps agency
Rankings and scores are advice. The client must still apply local policy and decide which candidate is acceptable for the actual task.
Nodes stay diverse
Different languages, runtimes, network locations and operating models should be valid if they satisfy the protocol contract and provide truthful evidence.
Claims become checks
Privacy, quality, compatibility and availability claims should move from reassuring prose toward manifests, tests, receipts and transparent rules.
Capture must be expensive, visible and reversible
IICP should not rely on the hope that powerful actors will remain benevolent. Governments, companies and dominant operators will naturally try to influence any useful coordination layer. The design goal is not a mesh without power struggles; it is a mesh where influence cannot quietly become control.
That requires open specifications, multiple implementations, portable clients, transparent scoring, reproducible evaluation, low switching costs and federated directories. These are not decorative governance ideals. They are structural safeguards against capture.
A participant should preserve three practical rights over time: the right to participate, the right to leave, and the right to reimplement. If those rights remain real, the network can be politically contested while still structurally open.
Why this matters for complex problem solving
Many future systems described as agents, adaptive workflows or machine-assisted organizations are blocked by coordination as much as intelligence. A model can produce an answer, but an ecosystem must discover tools, select providers, satisfy local policy, retry safely, record evidence and verify important claims.
IICP points toward accountable composition rather than a single mega-agent. A larger goal can be split into capability requests, each resolved against current network evidence. The client can keep agency over the task graph while using remote competence only where it is useful and acceptable.
If this matures, applications become partly local and partly network-composed: they keep their protected logic and identity, but extend themselves through selected capabilities from the mesh. That is the deeper implication: useful software is no longer bounded by one vendor account or one installed codebase.
Broader implications
An economy of on-demand competence
Software could keep its own identity and protected local logic while drawing specific capabilities from the network only when needed.
Coordination as the missing substrate
Many agentic systems are blocked less by missing intelligence than by missing discovery, policy selection, fallback and verification across independent actors.
Decentralization with memory
Open participation is not enough. A useful mesh needs memory about behaviour, visible scoring rules and ways to resist abuse without creating an absolute ruler.
Post-founder durability
If IICP matters, it must outgrow personal authority through traceable decisions, independent implementations, review, forks and federation.
Where support matters
Implement the protocol
Clients, nodes, SDKs, directory implementations and conformance tests need independent review and alternative implementations.
Run real nodes
The mesh only becomes meaningful when it is tested across home networks, datacenters, browsers, relays, different runtimes and imperfect conditions.
Audit the signals
Trust scoring, uptime, quality tiers, privacy claims and routing receipts need people who challenge whether the evidence actually supports the claim.
Shape governance before scale
Federation, rule changes, issue handling, scoring policy and reimplementation rights should be made clear before adoption pressure makes them harder to change.
Outlook
If this worldview aligns with yours, this is what you are implicitly supporting.
IICP should not replace MCP, A2A, ACP-style client protocols, or other agent standards. Its sharper role is to turn human or machine intent into the best available execution path across capabilities, providers, tools, organisations and jurisdictions.
The refined claim
IICP can become the intent-routing and capability-discovery layer of the Internet of AI: not the tool protocol, not the whole agent protocol, but the open layer that asks who can satisfy this intent under these constraints?
Autonomous IT and security
The fastest path to visible utility: hardening, DevSecOps, CI, dependency upgrades, incident response, observability and infrastructure repair.
Self-maintaining infrastructure · DevSecOps mesh · secure dependency upgrades
Federated capability markets
The economic engine: route work to compute, model, expert, creative or data capabilities by quality, cost, carbon, policy and reputation.
Global compute routing · creative production markets · specialist review agents
Cross-boundary coordination
The integration shift: organisations and public systems can exchange typed intents instead of building brittle one-off connections.
Enterprise workflows · emergency response · healthcare administration · citizen services
Human capability amplification
The civilisational upside: give more people access to learning, research, accessibility, language support and personal agency.
Personal AI router · scientific commons · personalised learning
The flagship demonstration remains self-maintaining infrastructure because it is concrete, valuable and testable. From there, the same pattern expands toward DevSecOps, compute routing, enterprise exchange, science, education, personal AI and public-good coordination.
A future use case is not a current safety claim
Education, healthcare, employment, public services, emergency response and other regulated areas are long-term possibilities, not ordinary public-mesh defaults. They require people with authority to remain accountable, affected people to have understandable review and appeal paths, and the concrete deployment to meet its legal and safety duties.
Outlook
The IICP-native portfolio: intent fulfillment across boundaries.
This section stays inside philosophy because it is the practical consequence of the worldview and a future alignment table for project direction. It assumes the protocol positioning already explained in the homepage expert comparison: IICP should not replace MCP, A2A, gRPC or client-interface protocols; it should specialise in intent routing and capability discovery. See the protocol comparison →
Regulated-use boundary
The portfolio below is an architecture outlook. It does not classify IICP as suitable for a high-risk AI deployment and does not authorize unattended legal or similarly significant decisions. A regulated deployment needs a defined intended purpose, role allocation, risk and privacy assessment, human oversight, traceability, incident handling and contestability outside generic route discovery.
When a use case is truly IICP-native
- • many possible providers can satisfy the task
- • the best provider changes with health, price, region or quality
- • privacy, latency, cost, jurisdiction or safety constraints matter
- • several specialised agents may cooperate
- • fallback, auditability and receipts improve the outcome
- • no single platform should own the whole workflow
Four strategic pillars
Autonomous IT and security
The fastest path to visible utility: hardening, DevSecOps, CI, dependency upgrades, incident response, observability and infrastructure repair.
Federated capability markets
The economic engine: route work to compute, model, expert, creative or data capabilities by quality, cost, carbon, policy and reputation.
Cross-boundary coordination
The integration shift: organisations and public systems can exchange typed intents instead of building brittle one-off connections.
Human capability amplification
The civilisational upside: give more people access to learning, research, accessibility, language support and personal agency.
Rank
1
Tier 1 flagship
Self-maintaining infrastructure
Autonomous IT and security
Machines, VMs, clusters and edge devices ask the mesh to bootstrap safely, harden themselves, verify the result and keep drift under control.
Why IICP matters
Turns infrastructure operations into routable expertise: Debian, Kubernetes, OpenSCAP, firewall, IAM, monitoring and rollback specialists can all contribute.
Example intents and primitives
infrastructure:secure-bootstrapos:hardening-plansecurity:drift-remediatetyped infrastructure intents · approval-aware change plans · signed hardening receipts
Rank
2
Tier 1
Software engineering and DevSecOps mesh
Autonomous IT and security
Developers route code review, security checks, dependency upgrades, incident debugging and regression testing to the best available specialists.
Why IICP matters
A practical adoption wedge because developers already understand agents, CI, package security, code review and automated tests.
Example intents and primitives
code:review-securitydependency:upgrade-safelytesting:generate-regression-suiterepo-aware policies · test evidence · IDE and CI/CD bridges
Rank
3
Tier 1
Global compute and energy-aware routing
Federated capability markets
Work can be routed to suitable compute by price, latency, region, privacy, model quality, idle capacity or carbon intensity.
Why IICP matters
One of the most IICP-native opportunities: capability discovery can become a real alternative to purely centralised AI compute markets.
Example intents and primitives
compute:find-low-carbon-gpucompute:run-batch-cheapcompute:route-local-firstpricing manifests · capacity signals · quality and region receipts
Rank
4
Tier 1
Enterprise intent exchange
Cross-boundary coordination
Organisations expose controlled capabilities to partners so procurement, logistics, onboarding, finance and security workflows can coordinate dynamically.
Why IICP matters
Reduces integration cost by replacing bilateral glue with typed, auditable capability exchange.
Example intents and primitives
procurement:request-qualified-supplierslogistics:quote-route-capacityfinance:invoice-reconcileorganisation identity · delegated authority · audit exports
Rank
5
Tier 1 / Tier 2
Personal AI intent router
Human capability amplification
Your devices keep private context local and discover external skills only when a task is safe and useful to outsource.
Why IICP matters
Reframes the personal assistant as a user-owned policy router, not another central super-assistant silo.
Example intents and primitives
personal:research-with-citationspersonal:calendar-negotiatepersonal:travel-plan-privatelocal policy node · consent rules · receipt log
Rank
6
Tier 1 / Tier 2
Scientific capability commons
Human capability amplification
Researchers discover compute, datasets, models, verification agents and replication partners across institutions.
Why IICP matters
The uniquely important feature is replication routing: who can independently verify this result?
Example intents and primitives
science:run-simulationscience:replicate-resultbioinformatics:variant-annotationprovenance graph · dataset matching · replication receipts
Rank
7
Tier 2
Personalised learning network
Human capability amplification
A learner receives explanations, exercises, simulations, tutors and peer support adapted to their level, language and goals.
Why IICP matters
The goal is not one AI tutor; it is an adaptive learning graph that finds the right explanation and practice path.
Example intents and primitives
education:explain-concepteducation:generate-practice-planeducation:simulate-lablearner-owned progress · accessibility signals · teacher oversight hooks
Rank
8
Tier 1 long horizon
Emergency and resilient infrastructure coordination
Cross-boundary coordination
Local or permissioned federations discover resources and coordinate help when normal channels are overloaded or degraded.
Why IICP matters
Emergency response is a capability-routing problem under uncertainty: beds, generators, medicine, roads, bandwidth, people and authority.
Example intents and primitives
emergency:allocate-medical-suppliesgrid:stabilize-local-loadnetwork:restore-critical-linksovereign federation · signed situational reports · command-chain integration
Rank
9
Tier 1 long horizon
Robotics, edge and physical-world coordination
Cross-boundary coordination
Robots, sensors, drones, factories, farms and device fleets discover local expertise and coordinate work at the edge.
Why IICP matters
Future AI will not stay in chat windows; intent routing can help physical systems find specialised local capabilities.
Example intents and primitives
robotics:fleet-routedrone:search-areaiot:diagnose-device-fleetlocal fail-safes · real-time constraints · edge identity
Rank
10
Tier 2
Creative and economic capability markets
Federated capability markets
Creators assemble specialist helpers for concept, writing, image, video, music, localisation, editing, rights and distribution.
Why IICP matters
The protocol opportunity is not just generation; it is rights-aware composition, attribution, payment and provenance.
Example intents and primitives
creative:compose-campaigncreative:license-checkcreative:rights-clearancerights manifests · provenance chain · royalty receipts
Rank
11
Tier 2 regulated path
Healthcare administration and care coordination
Cross-boundary coordination
Administrative care work such as scheduling, prior authorisation, literature support, trial matching and patient navigation becomes easier to coordinate.
Why IICP matters
The safer entry point is not autonomous diagnosis; it is reducing paperwork and coordination friction around care.
Example intents and primitives
healthcare:prior-auth-preparehealthcare:care-plan-coordinatehealthcare:trial-matchcare-context boundaries · provider identity · auditable handoffs
Rank
12
Tier 2
Public-sector and citizen service agents
Cross-boundary coordination
Citizens get help understanding services, forms, benefits, language barriers and legal questions without one opaque automation deciding outcomes.
Why IICP matters
Strong public-good case: reduce friction between people and institutions while keeping explanation and human routes visible.
Example intents and primitives
public:benefit-eligibility-explainpublic:form-completion-assistlegal:triage-citizen-questionexplainable guidance · human escalation · service provenance
If this clicks
Try it, read the roadmap, run a node, improve the docs, or challenge the claims. Supporting IICP means helping test whether open intent-based coordination can become real infrastructure.
What must still be proven
Security and privacy
Remote nodes still see work they execute. Key handling, relay confidentiality, metadata exposure and fail-closed behaviour must stay evidence-led.
Signal quality
Quality tiers, reputation, uptime and conformance need reliable measurement, transparent rules and resistance to gaming.
Federation timing
Federation is the long-term direction, but premature federation can freeze mistakes. The core contract must stabilize first.
Continue from philosophy to proof
The philosophy only matters if it becomes implementation discipline: protocol contracts, conservative privacy claims, live evidence, testable node behaviour, honest roadmap gates and a path toward independent operation.