The core loop is simple: - publish an event - get back a frame if it should enter the human attention surface - render that frame in your UI/workflow - submit the human response back into the engine
As agents get more capable and one human starts supervising more of them, the bottleneck shifts toward human attention.
A lot of agent tooling focuses on orchestration, tool use, memory, or traces. Aperture Core is centered on a different question: what should actually reach the human, when, and in what form?
At a high level, the engine separates: - policy: what is allowed to interrupt - value: what is actually worth attention now - planning: whether something should be active, queued, or ambient
The basic idea is that human attention is a constrained system resource, and most agent UX doesn’t model it explicitly.
It’s deterministic in the hot path, but can optionally adapt over time from the human’s response patterns, deferrals, context expansion, and disagreement history.
That also means it can be used as a first-pass filter before involving a model or more expensive reasoning step.
The SDK is published on npm as @tomismeta/aperture-core.
The repo has a package-facing README and examples showing the basic loop:
event in -> frame out -> human answer in -> state updates
Would especially love feedback on:
- whether the API is intuitive for first-time SDK consumers
- whether the frame/response model makes sense
- where this should stay deterministic vs eventually use a model