HexStellar Cortex: an agent-first execution service with receipts, and a licence you cannot read

The problem: an agent that can describe a decision but not compute it

The README states the premise directly: language models are good at reading a messy request, naming constraints and proposing alternatives, but "imagination is not execution." Once the search space is large, a fluent answer stops being useful. HexStellar's answer is to give the agent a separate place to send the hard part, so the model handles interpretation and formulation while the service handles the search and returns a structured result with its measured cost and assurance. The intended user is not a human typing solver syntax. It is an agent, or a developer wiring an agent, that needs a machine-readable contract to call. The README frames the catalogue as "recipes, not boundaries" and tells the agent to translate entities, constraints, objectives and scale rather than hunt for an example with a matching industry name. That is a deliberate design stance: the examples teach transferable shapes, and the executable surface is whatever hexstellar capabilities reports at the moment of the call.

Two surfaces, and only one of them is public in 1.0

HexStellar is described as one platform with two delivery surfaces. Cortex runs on HexStellar-managed infrastructure: the user installs a thin client, the request goes out, HexStellar's acceleration technology runs it on their servers. Enterprise Low-Energy Runtime and Acceleration is the same technology shipped as a licensed library for customer-controlled infrastructure, covering applications, frameworks and model-serving stacks. The README is explicit that Enterprise access is arranged directly under NDA and that "public download and automatic activation are not available in 1.0." It also states that published measurements currently cover only identified GPU-inference campaigns, and that IoT or ESP-class support depends on an issued Enterprise build rather than being a public-download promise. That is a meaningful boundary. If your requirement is on-premise or air-gapped execution, the 1.0 source in this repository does not give it to you, and there is no self-serve path to get it. The architecture is described as designed for those deployments; the availability is not there yet.

What the CLI actually exposes

The README's quickstart is four commands. pip install hexstellar installs the client. hexstellar demo runs something without arguments. hexstellar route "describe the real problem you want my agent to formulate" takes a natural-language description and, based on the name and the surrounding text, routes it toward a supported contract. hexstellar capabilities reports what is executable now, which is the command the README tells the agent to consult before assuming a formulation is supported. Two further flags appear in the same passage: validate and --dry-run, described as keeping creativity inside a measurable contract, and verify for checking a result. The README also points to AGENT_SPEC.md for a pure-HTTP quickstart, which matters if you would rather not install a package at all. What the README does not give is the shape of the request or response payloads, the list of contract names, or worked examples of validate and verify output. Those live in the catalogue and the spec file, neither of which is reproduced here, so treat the CLI surface as confirmed at the level of command names and not at the level of syntax.

Installation is a two-path decision, and the README says which path to take

The distribution status note is the most operationally important paragraph in the repository. This repository is the public HexStellar CLI 1.0 source, but the PyPI 1.x distribution is "activated in a separate, audited release step." Until pypi.org/project/hexstellar reports a 1.x release, the README instructs you to install from source with python -m pip install "git+https://github.com/brayonpi/hexstellar.git" or to use the pure-HTTP quickstart in AGENT_SPEC.md. It adds a warning that the historical PyPI placeholder should not be treated as this client. That is an unusual thing to have to write, and it tells you something about the release process: the artifact most people would reach for by default is not the artifact the maintainers want them to use. If you are evaluating this for anything with a supply-chain review, the source-install path means you are pinning a git ref rather than a versioned wheel with a hash, and you should confirm the audited PyPI release has landed before you build a dependency policy around it.

The licence identifier is NOASSERTION, and that is the real adoption blocker

The repository metadata reports the licence as NOASSERTION. That is not a licence name. It means the automated classifier could not map whatever licence file or text is present to a recognized identifier, and it is the same result you get for a bespoke licence, a modified licence, or a file the tooling simply failed to parse. The README does not resolve the ambiguity: it describes Enterprise access as licensed and under NDA, and it says the Enterprise runtime has no public download, but it never states the terms under which the Cortex CLI source itself may be used, modified or redistributed. For a thin client that talks to a managed service this may be entirely workable, but you cannot determine that from the material here. Read the actual licence file in the repository before you ship anything that depends on it. This is not legal advice; it is a statement that the metadata gives you nothing to reason with.

Where the design gets interesting: certainty labels and receipts

The most substantive idea in the README is the assurance rule. It says to read the per-result certification and verification fields, and that "determinism, heuristic search, sampling and verified operations are distinct semantics." In other words, a result carries a label describing what kind of guarantee it actually has, and the platform refuses to flatten a heuristic answer and a proven one into the same output shape. The README also promises that the result comes back with its measured cost and its receipt. For agent-driven work this is the correct instinct, because the failure mode of an LLM plus a solver is a confident answer with no provenance. A receipt and a certainty label give the calling agent something to branch on: accept, retry with a different formulation, or abstain. The README's own instruction to the agent is to "explain the boundary and abstain" when no honest formulation exists, which only works if the contract makes the boundary machine-checkable. The catch is that none of this is demonstrated in the README. You get the vocabulary of certification and verification without a sample receipt, so the practical question of what a label looks like and how you would assert on it in a test is unanswered by the material available.

When a local solver is the better tool

The clearest alternative is a self-hosted modelling library such as OR-Tools or Pyomo driving a solver you install yourself. The difference is not capability, it is where the search runs and who can inspect it. With OR-Tools you write the model in Python, choose CP-SAT or a MIP backend, and the whole thing runs in your process with no network call. You can read the solver source, pin an exact version, run it offline, and reproduce a result months later from the same lockfile. What you give up is the part HexStellar is selling: you own the formulation, so there is no service translating a natural-language problem description into a contract, no managed acceleration, and no receipt issued by a third party. There is also no certainty label unless you build one, and building one is genuinely hard, which is the honest argument for paying for this. The trade-off is legible. If your problems are small enough to formulate by hand and your environment forbids outbound calls, a local solver wins on every axis that matters. If your agent is generating formulations faster than a human can review them, the receipt is the feature.

Maintenance cost and what to check before you commit

The repository shows a single release, v1.0.0, pushed on 2026-08-27 alongside the last push to main. There is one data point, so there is no upgrade history to reason about and no evidence of how breaking changes are handled between versions. The CLI is the only public artifact, and because the README directs source installs until the audited PyPI release lands, your upgrade path currently involves watching both the repository and the PyPI project page. The Enterprise runtime is a separate track entirely: licensed, under NDA, no public download, and no automatic approval, which means evaluating it is a commercial conversation rather than a pip command. Start with hexstellar demo and hexstellar capabilities against a real problem, and check whether the contract you need is listed. Then read the licence file, because NOASSERTION is the one field in this repository that can stop an adoption on its own.

Editorial conclusion

Adopt HexStellar if your agent needs to hand a structured formulation to an execution service and you want the returned certainty label, measured cost and verification receipt to be explicit rather than implied. Do not adopt it if you need an auditable open source solver you can read, patch and ship, or if you need offline execution in 1.0, since the Enterprise runtime has no public download. Before committing, verify three things: that pypi.org/project/hexstellar reports a 1.x release rather than the historical placeholder, that the repository licence file actually resolves the NOASSERTION identifier to a name you can accept, and that the contracts you need appear in the output of hexstellar capabilities rather than only in the example catalogue.

Official sources

1. brayonpi/hexstellar on GitHub
2. Issues
3. README
4. Releases