impanyu/agentic_services

Agentic Services is a multi-service platform for human users, autonomous agents, or both. Each service owns a focused capability and can be sold independently through the appropriate user-facing and/or machine-facing channel.
Services belong to one of three product categories:
- **Human-only:** designed for people to use through a UI; no agent-callable interface is required.
- **Agent-only:** designed for autonomous agents to discover, purchase, and invoke through a machine interface; an informational product page is not a human-use UI.
- **Human-and-agent:** provides both a usable human UI and a machine service interface for the same underlying capability.
The category describes intended users, not whether a website or API happens to exist. APIs, MCP tools, and A2A services are possible machine transports; a human UI is a separate product surface.
Product contract
Every published service has a stable identity, its own offer and delivery contract, a payment path, and service-level and policy information. Requirements depend on its category:
- Human-only services need a usable UI and human checkout or entitlement flow.
- Agent-only services need a machine-readable description, input/output schemas, a callable transport, and machine-compatible pricing and payment.
- Human-and-agent services need both complete surfaces, backed by the same service identity and consistent results and commercial terms where applicable.
- Paid delivery must be metered and recorded. Machine calls require idempotency and verifiable receipts; human transactions require an order record and appropriate receipt.
- Data services publish provenance and freshness appropriate to their claims.
For services with an agent interface, the canonical public manifest lives at:
The same manifest can be indexed by the platform registry and exported to compatible discovery networks. Human-only services do not need an agent manifest.
Repository layout
The initial protocol is defined by schemas/service-manifest.schema.json. An illustrative service is in examples/weather-risk.service.json.
Architecture
The platform has four layers:
- **Service layer** — focused information products owned by individual service modules.
- **Gateway layer** — identity, quotes, payment verification, rate limits, and receipts.
- **Registry layer** — capability search, health, reputation, and machine-readable manifests.
- **Settlement layer** — adapters for pay-per-call, credits, and subscriptions.
See docs/architecture.md for the execution flow and docs/roadmap.md for the build sequence.
For Niche Discovery, see the continuous collection and agent-analysis design.
Its Niche Manager Agent owns autonomous research and knowledge-base maintenance through an extensible tool registry, memory, periodic runs and event-driven wakes.
Design principles
- Protocol-first for agent-facing services: an agent can integrate from schemas without reading prose.
- Narrow services: each service owns a small domain and returns a useful result, not raw data alone.
- Payment-neutral core: commercial terms are stable while payment rails remain replaceable.
- Verifiable delivery: paid transactions have an order record; machine executions have a receipt tied to the request, price, and result.
- Safe autonomy for machine purchases: budgets, expiry, replay protection, and idempotency are enforced in deterministic code.
- Federated discovery: the platform registry is useful but is not the only way to find a service.
Run Web Evidence locally
The first runnable service is **Web Evidence**, a structured claim-verification API backed by the OpenAI Responses API and hosted web search.
The API starts at http://localhost:8000. Its main endpoints are: