Skip to content
Intrinsic Core: how to quote a client project built on it
Back to Blog
#Intrinsic Core#open source robotics#real-time control#Apache 2.0 licence#ROS 2#software contracts#reshaped-v3

Intrinsic Core: how to quote a client project built on it

Uzair bin Haroon

Quote it time and materials, and name a release tag in the contract. Intrinsic Core is Apache-2.0, and under the licence sits one sentence from the people who wrote it: "This is not an officially supported Google product." No support contract, no service level, no escalation path. Its releases are date stamps — 20260921.0, then 20260922.0 twenty-nine hours later — not semantic versions, and a date stamp promises nothing about what changed between two of them.

That is the commercial answer, and it is not a reason to walk away. The engineering is serious and the licence is generous. It is a reason to put the version you built against into the scope of work rather than a README, and to price every upgrade as new work.

The releases page for intrinsic-ai/intrinsic-core showing tags 20260922.0 and 20260921.0
From intrinsic-ai/intrinsic-core releases on GitHub, read 23 September 2026

What your client is actually asking you to build on

Nine C++ modules, public on GitHub since 8 September. intrinsic_runtime is a local execution engine packaged as a k3s container environment, sitting on ROS 2 and handling process lifecycle and state so you do not wire that up yourself. intrinsic_control — they call it ICON — is the real-time engine: kinematics, trajectory interpolation and a deterministic loop that the README says can switch controllers "within a single cycle based on live sensor feedback". Around those sit motion planning, perception, on-edge inference, an SDK, the API definitions, hardware drivers and a kinematics library.

The prerequisites are pins, not suggestions: Ubuntu 24.04 or 26.04, with 22.04 supported, against ROS 2 Lyrical Luth. If the client's target hardware does not match that list, the work of making it match belongs in your estimate before anything else does.

Is the engineering good enough to build a business on?

The sibling repositories answer that better than any marketing page. malloc-guard is described in Core's own README as a "real-time C++ library for detecting and preventing dynamic heap allocations in real-time threads" — a library that only exists because somebody spent a long time chasing the jitter a stray allocation causes in a hot control thread, the kind that ruins a surface finish once every few thousand cycles and never reproduces on the bench. Beside it sit icon-shared-memory, the transport the control stack uses, and icon-hwm-controller, which bridges ros2_control into the real-time path. That is a team working on the load-bearing problems.

One detail belongs in your risk register rather than your pitch. The public GitHub description of malloc-guard still reads "Staging repository for MallocGuard, currently going through go/intrinsic-open-source" — an internal link left on a public repository. The open-sourcing is a process still running, so repository names and locations can still move under a build that depends on them.

The five clauses to write

None of them are unusual, and all five come straight out of the two facts at the top.

  • Name the tag. The build is against 20260922.0, or whatever is current the day you sign, and that string goes in the scope.
  • Every bump is a change order, priced after someone has read a diff they did not write. Nobody upstream is going to backport a fix for you.
  • Say who owns the upgrade for the length of the support term, and what staying current costs per year.
  • Say what happens if upstream stops. Apache-2.0 means you can fork it; the clause is about who pays to maintain the fork.
  • Budget the contribution path if you intend to push anything back: the Google Contributor Licence Agreement has to be signed, and the code has to be C++20.

Add the trademark to the list of things you tell the client early. The code is open; the names "Intrinsic" and "Intrinsic Core" belong to Intrinsic Innovation LLC, so the client's product cannot be built around that word. This is the same discipline that belongs in any contract built on somebody else's fast-moving software — who owns the upgrade, who carries the risk, what happens if the supplier walks away — and it is the discipline agent projects need too.

The signal to watch for, if you want to fix-price a phase later: a semantic version. A 1.0.0 would mean the maintainers are promising an interface rather than a date, and that is the point at which a fixed price stops being a bet on someone else's roadmap. Two weeks of public history and two releases is not that point.

If you would rather hand the version-tracking and the upgrade diffs to someone who does it every week, Vesprr builds and maintains integrations like this — send over the scope you have been asked to quote.

Sources