Iii

{
  "service_type": "platform",
  "base_url": "https://iii.dev",
  "auth_method": "unknown",
  "auth_config": {},
  "endpoints": [],
  "pricing_model": {
    "type": "unknown",
    "details": {
      "notes": "No pricing information found on the provided plain-text snapshot. Described as 'one open-source engine', implying the engine itself is free/open-source, but hosting, managed services, or support pricing is not documented in the provided content."
    }
  },
  "rate_limits": {},
  "capabilities": [
    "Open protocol (JSON over WebSocket) engine for backend orchestration",
    "Three primitives: Worker, Trigger, Function",
    "Polyglot worker support (TypeScript, Python, Rust, Node.js, browser, edge, embedded, microVM)",
    "Real-time composition, extension, and observation of services",
    "Engine-mediated routing, serialization, tracing, and delivery",
    "Declarative triggers: HTTP routes, cron, queues, state changes, stream events, direct calls",
    "Durable orchestration for long-running, failure-tolerant execution",
    "Interoperable cross-language execution",
    "Runtime worker creation and dynamic capability extension",
    "Agent-native runtime (agents as Workers, tools as Functions, memory as state, orchestration as Triggers)",
    "Self-hosted and polyglot deployments as first-class",
    "Worker registry (workers.iii.dev) for discovering/publishing workers",
    "End-to-end tracing across languages and processes"
  ],
  "raw_analysis": "iii (pronounced 'three eye') is a development platform and open-source engine positioned as a unifying execution substrate for distributed backend systems. Rather than being a traditional SaaS product with a public REST API, iii appears to be an infrastructure runtime that you self-host or run, exposing an open protocol (JSON over WebSocket) as its primary interface — not a documented REST API.\n\n**What it does**: iii collapses common backend integration categories (queues, cron, HTTP, state, streaming, observability, sandboxes, agents) into a single engine with exactly three primitives:\n- Worker: any process (in any language/runtime) that connects to the engine and registers functions/triggers. Can be a service, browser tab, edge function, Raspberry Pi, or microVM.\n- Trigger: anything that causes a function to run (direct call, HTTP route, cron, queue subscription, state change, stream event).\n- Function: a unit of work with a stable identifier that lives inside a Worker.\n\nThe core thesis is that integration cost across N services grows combinatorially (N²), and iii aims to drive that toward zero by making every capability a Worker on the same protocol. Adding 2 or 200 workers is the \"same operation.\"\n\n**Who it's for**: \n- Application teams wanting to compose backend services without bespoke glue code per integration.\n- Platform teams publishing reusable worker capabilities.\n- Teams building polyglot, self-hosted, or edge-distributed backends.\n- AI agent developers: iii positions agents as first-class Workers whose tools are Functions, memory is state, and orchestration is Triggers — the runtime IS the agent's runtime, reducing token cost and context complexity.\n\n**Maturity**: The marketing copy is ambitious and positions iii against a wide range of adjacent categories (event streaming, microservices, workflow orchestration à la Temporal/Step Functions, message queues, service meshes, Kubernetes, serverless, RPC frameworks, job schedulers, actor frameworks, IaC, API gateways, BaaS). It has a worker registry (workers.iii.dev), documentation (iii.dev/docs/install), and an AGENTS.md for builders, suggesting active development. However, the provided content contains no version numbers, release history, funding, team info, or adoption metrics — maturity is difficult to assess beyond the existence of docs, a registry, and a well-articulated positioning. The presence of installation docs implies it is usable today, but this appears to be an early-stage product (likely startup/seed stage) with high-ambition claims.\n\n**Integrations**: iii's integration story is inverted — rather than offering pre-built integrations to popular tools, iii expects you to add integrations as Workers. The worker registry acts as a discovery layer. No specific named third-party integrations (Slack is mentioned only in an example UX flow, not as an official integration), databases, or cloud providers are documented in this snapshot beyond language runtimes (Node.js, Python, Rust).\n\n**Pricing**: Not disclosed in the provided content. Described as 'one open-source engine', implying the core is free/open-source. No pricing page content was included. Likely a freemium or open-core model with potential paid hosting/support, but this is speculative.\n\n**API access note**: This is explicitly NOT a REST-API platform in the conventional sense. The primary interface is the open WebSocket protocol. The snapshot explicitly states 'this file is for understanding iii, not for

3/3 tests passed

```json
{
  "overall": 74,
  "dimensions": {
    "token_efficiency": 7.5,
    "first_try_success": 6.5,
    "response_parseability": 8.5,
    "error_clarity": 6.0,
    "doc_quality": 7.5,
    "auth_simplicity": 7.0,
    "latency": 9.5,
    "consistency": 8.0
  },
  "pricing_normalized": {
    "model": "open-source",
    "notes": "Engine is described as free/open-source. No documented pricing for hosting, managed services, or support. Agents cannot quote a cost to users — a gap for budget-sensitive recommendations."
  },
  "issues": [
    "No pricing information available: unclear whether managed hosting, support, or enterprise tiers cost anything, which blocks cost-based recommendations.",
    "Onboarding friction unknown — polyglot worker setup (TypeScript/Python/Rust) implies a real backend engineering effort before value is seen; not a '2-minute' product.",
    "Three abstract primitives (Worker/Trigger/Function) require explanation; value prop takes several sentences to land, hurting token efficiency.",
    "No explicit auth model documented in the snapshot (self-hosted likely, but agent-facing signup path is unclear).",
    "robots.txt disallows /roadmap and /docs/_next/, mildly limiting agent-crawlable depth on future/versioned content.",
    "Doc/error-clarity claims can't be verified from the snapshot alone — limits confidence in error_clarity score."
  ],
  "recommendations": [
    "Publish a clear pricing page (self-host free, managed tier X, support Y) so agents can compare against alternatives.",
    "Expose an explicit auth/signup flow doc (SSO, API keys, self-host bootstrap command) to enable agents to guide users through onboarding.",
    "Provide a one-line value prop plus a 3-command quickstart so agents can onboard users in a single message.",
    "Add machine-readable openapi/schema for the JSON-over-WebSocket protocol so agents can generate correct client code first try.",
    "Surface a status page + versioned changelog in robots-allowed space to support consistency/uptime claims.",
    "Ship a hosted playground or sandbox so first-try-success isn't gated on local polyglot setup.",
    "Reduce primitive naming ambiguity — Worker/Trigger/Function overlap with common terms (Cloudflare Workers, Lambda triggers); document disambiguation to avoid agent misrecommendation.",
    "Ensure llms.txt and a structured /llms-full.txt or JSON manifest exist for dense agent ingestion."
  ]
}
```