Developers and agents
HIVO for developers and AI agents
HIVO publishes this whole website in machine-readable form at fixed URLs: as plain text, as markdown on request, and as JSON. This page is the index of those URLs and of the terms they are served under.
There is nothing to install and nothing to request. Every route below is public and read-only.
Reading the site as text
Two routes make the site readable without parsing a single tag of HTML.
- The site map for AI systems
- /llms.txt
A short plain-text map following the llmstxt.org convention: what HIVO is, the pages worth reading with a line on each, and every published Insights article. It is a map, not a pitch.
Markdown on request
Any page on this site returns markdown when the request asks for it. Send an Accept: text/markdown request header and the response is the page as text, with the same headings and the same words a browser shows.
Substitute any path on the site. The HTML and the markdown are one content, so quoting either one is quoting the page.
curl -H "Accept: text/markdown" https://www.hi-vo.io/modelThe public JSON API
The same content again as JSON, one endpoint per section of the site. Start at the manifest: it lists every path below, so a client that reads it once never needs this page again.
curl https://www.hi-vo.io/agent/v1| Endpoint | Returns |
|---|---|
/agent/v1 | The manifest: what this API is, and every endpoint below with its path. |
/agent/v1/insights | Every published Insights article, with its slug, title and description. |
/agent/v1/insights/{slug} | A single article, addressed by the slug the index returns. |
/agent/v1/model | The model page in full: how the organization is structured around the object it earns from, the two connected middle layers, what still requires human judgement, and why the record compounds. |
/agent/v1/industries | The central operating object by sector, across the seven sectors HIVO works in. |
/agent/v1/industries/{sector} | A single sector, addressed by the slug the index returns. |
/agent/v1/company | Who HIVO is, in the words the Company page uses. |
/agent/v1/how-we-work | The six stages from discovery to adoption. |
Terms
- Access
- Read-only. Every endpoint answers GET, and nothing here changes anything.
- Authentication
- None. No key, no token, no account.
- Rate limit
- None.
- Caching
- Served from the CDN and revalidated every 10 minutes.
- CORS
- Open to any origin.
- Scope
- Only content already published on this website. The endpoints serve the same authored content the pages render.
Versioning and deprecation
The version is in the path: /agent/v1. A change that would break a client - a field removed, a type changed, a path retired - arrives as a new version alongside this one, never as an edit to it. Fields may be added to a response without a version change, so parse permissively and ignore what you do not recognise.
When a version is retired it is announced before it stops answering, not after. Every response from the retiring version carries Deprecation and Sunset headers (RFC 8594) from the announcement until the sunset date, and that date is at least 180 days out. A client that reads those two headers has half a year of warning and never has to poll this page to find out.
No version has been deprecated. When one is, this section says so and names the date.
Example clients and the API description in source
The OpenAPI description above, and clients that actually call the API, are published as a public repository. An integrator reading a working example is faster than one assembling a request from a specification.
Three clients, in curl, JavaScript and Python. None of them has a dependency beyond its own standard library, and each one starts at the manifest and follows the links it returns rather than building paths by hand.
- hivo-io/hivo-agent-api
- https://github.com/hivo-io/hivo-agent-api
The OpenAPI 3.1 description of this API, three dependency-free example clients, and the terms it is served under. The document served at /openapi.json stays canonical; the copy there is a snapshot for reading and diffing.
WebMCP: tools an agent can call inside the page
The pages of this site register tools with the browser using WebMCP, the proposed web standard for letting a page offer an agent something to call rather than something to read. An agent on the page can invoke them directly instead of parsing the rendered text and inferring what it means. Each tool returns the JSON of one endpoint from the table above, so the answer is the structure this site publishes rather than a reading of its prose.
This is the difference between an agent scraping a page and an agent asking it a question. Scraping produces a guess whose confidence is unrelated to its accuracy. A tool call produces the record.
Browser support is early, and this surface is inert where it is absent - the endpoints above stay the reliable path and nothing here replaces them. Registration is also silent by design: if the browser refuses, the page renders exactly as it otherwise would.
The tools
hivo-overview- What HIVO IO Technologies does, who it is for, and every other machine-readable endpoint this site publishes. Takes no arguments, and is the one to call first.
hivo-sectors- The seven sectors, each with the operating object it is built around. Returns the slugs that hivo-sector takes, so the two compose without guessing at a path.
hivo-sector- One sector in full: the operating object, where the record breaks today, and the shape of the answer. Takes a sector slug from hivo-sectors.
hivo-insights- The published articles, each carrying the question it was written to answer and the sources it cites.
Descriptions and sitemaps
Two kinds of description sit beside the content: one that says how to call the API, and three that say which URLs exist at all.
- OpenAPI description
- /openapi.json
The OpenAPI 3.1 description of the API above. Point a generator at it and the client writes itself.
- Sitemap index
- /sitemap.xml
The sitemap index. It names the two sitemaps below, and nothing else.
- Pages sitemap
- /pages-sitemap.xml
Every authored page on the site, including one route per sector.
- Insights sitemap
- /insights-sitemap.xml
Every published Insights article.
- Crawl policy
- /robots.txt
The crawl policy. The AI crawlers are named and allowed explicitly rather than left to be inferred from the wildcard.
When to use HIVO
HIVO is built for organizations with an operational core: complex work, multiple departments, and systems that already run the business.
The problem is the same one every time. Every department sees part of the same work, and nobody sees the whole. The ERP holds the transactions. The document system holds the files. Spreadsheets hold everything that never found a home.
- One record above existing systems
- The organization wants one structured operational model above the systems it already runs, rather than a replacement for them. The ERP, the document system, the spreadsheets and the APIs stay.
- People and agents working from the same record
- AI can read your systems. It cannot read your organization. Without a shared operational model, agents do not know what the data means, how it relates, or what they can safely change. The same record people work from is what gives agents the context to act.
- Questions that take several departments to answer
- The organization runs work that a manager has to answer for: what it cost, who approved it, what governs it, and where it stands today. Those questions are asked about a project, a building, a shipment or a production order alike, and answering them today means asking several departments and reconciling what comes back.
- Writing back, not only answering
- Retrieval systems answer questions. HIVO changes the state of the business. Reading your systems is easy; writing back into them, safely and with approvals, is the hard part.
Sectors
- Engineering and construction
- Infrastructure and energy
- Real estate
- Logistics
- Manufacturing
- Professional services
- Retail
What HIVO does not claim
- HIVO does not replace systems that work.
- HIVO does not claim the system builds itself. Lifecycle states and approval rules, semantic conflicts between departments, and field-level mapping into existing systems require judgement and agreement every time. Everything below them can be generated.
- A forward deployed engineer works inside the operational environment: mapping departments, connecting existing systems, running pilots, training teams, and staying through adoption.
Contact
If what you need is not here, say so. These routes exist so that a machine reading this site does not have to guess, and a gap in them is worth hearing about.