Skip to content

Systems

Project Feldspar

A bounded autonomous-agent experiment that keeps operator authority separate from an agent workspace treated as fully compromiseable.

Identification

Reference
L3D-SYS-001
Class
experiment / platform
Maturity
active
Primary field
AI & Autonomous Systems
Fields
AI & Autonomous Systems, Reliability & Assurance, Business & Venture Systems
Practices
Observe, Control, Protect, Verify, Recover
Record route
/systems/project-feldspar
Content reviewed
2026-09-03

Purpose

An autonomous agent is useful in proportion to what it is allowed to do, and dangerous in the same proportion. Project Feldspar exists to find out how much capability an agent can be given when the authority to commit consequential change stays somewhere the agent cannot reach.

The operator is the only intended user. Nothing here is built for a customer, and no result is offered as a service.

Operating model

The experiment separates two things that are usually conflated. The agent workspace is where work happens, and it is treated as fully compromiseable: anything inside it may be wrong, captured, or adversarial. Operator authority is where consequential change is approved, and it is deliberately outside the workspace.

Work moves in one direction. The agent proposes; the operator disposes. A proposal that cannot be inspected is not a proposal, so the experiment values evidence that survives the agent that produced it.

Practices

Control is the reason the system exists: authority is an explicit boundary rather than a convention, and every consequential transition has a named place where it is granted.

Protect follows from treating the workspace as compromiseable. The interesting question is not whether the agent is trustworthy but which consequences must remain outside its reach when it is not.

Observe keeps the operator’s picture of the run grounded in collected evidence rather than in the agent’s own account of itself.

Verify and Recover cover the two failure paths that matter for a long-running autonomous process: proving that an intended change actually landed, and being able to reconstruct what happened when it did not.

Architecture

The published architecture is deliberately bounded. What can be said is the shape: a workspace with no standing credentials for consequential systems, an approval boundary that is a different trust domain rather than a different function call, and evidence written where the agent cannot revise it.

The rejected shortcut is the obvious one — giving the agent the operator’s own credentials and relying on prompt-level restraint. Restraint expressed only in instructions is not a boundary.

Evidence

The canonical repository is private, and the trust architecture is published only in redacted form. That is a deliberate limit rather than a temporary one: the useful part of this record is the reasoning, and the reasoning does not require the topology.

Availability

Documented, not offered case-study-only · not-offered

Documented as a case study. The experiment is not offered for deployment, licensing, or purchase.

The operator repository is private. Infrastructure, credentials, hosts, and deployment topology are not published.

Capabilities demonstrated

Repeatable work this system is evidence for. The relationship is authored on this record.

Evidence

  • private Operator repository and agent workspace definitions
  • redacted Authority and trust-boundary architecture

Systems

Stack

TypeScript · Model-driven agent tooling

There is no paid offering, price, or engagement on this site today. When one exists it will appear here as a record, with its scope and its exclusions.