Architecture guide · July 29, 2026
Permanent identity, replaceable harnesses
This operating model treats the agent as the accountable employee and the model or harness as replaceable compute. This page documents that design premise; it does not certify a portable snapshot package.
Why model-bound identity fails
If role, scope, memory, and work history exist only inside one model session, changing compute can silently create a new worker. The business then loses continuity and cannot reliably attribute decisions or performance.
The continuity anchor
The Buzz design uses a stable identity record as the anchor for the agent's name, business, team, supervisor, owned outcome, scope, permissions, skills, proof obligations, scorecard, and version history. ACP-compatible harnesses can be assigned to that record without becoming the record.
What a portable snapshot must prove
- The same identity and role remain addressable after a harness change.
- Permissions and memory boundaries do not expand during the change.
- Work history and proof references remain attached to the identity.
- The candidate package passes failure tests and independent inspection.
- Export, import, rollback, and version readback are captured as evidence.
A stable lead identity
A stable workflow lead identity can serve as the continuity anchor. Keep keys, model history, and private runtime details out of public examples. A signed native response, delegated job, proof object, independent verdict, and snapshot import round trip remain the acceptance chain.
FAQ
What should stay permanent when an agent's model changes?
Its business identity, role, owner, scope, permissions, memory boundary, work history, and proof references should remain attributable.
Is a model session the agent identity?
No. A model or harness is replaceable compute; the accountable identity is the stable business record.
When is identity portability proved?
After export, import, authority readback, live task evidence, rollback, and independent inspection pass.