What would you like?
I’d like Acolyte to use agent as the canonical term across the project instead of assistant.
This should be a clear project-wide rename, not a partial cleanup in one subsystem.
Motivation
Acolyte is an agent. Keeping assistant in core naming makes the model of the system harder to understand and creates unnecessary ambiguity about what the runtime actor actually is.
A partial rename would be more confusing than either staying with assistant everywhere or moving fully to agent. The terminology should describe one concept consistently.
Proposed approach
Rename assistant to agent wherever the code, contracts, UI text, and documentation are describing Acolyte itself.
Only keep legacy terminology where an external standard or unavoidable compatibility boundary requires it, and make that boundary explicit.
Scope
- core runtime naming
- chat and session contracts
- RPC and API payloads
- UI and CLI wording
- tests and documentation
- persisted data and compatibility boundaries
What would you like?
I’d like Acolyte to use
agentas the canonical term across the project instead ofassistant.This should be a clear project-wide rename, not a partial cleanup in one subsystem.
Motivation
Acolyte is an agent. Keeping
assistantin core naming makes the model of the system harder to understand and creates unnecessary ambiguity about what the runtime actor actually is.A partial rename would be more confusing than either staying with
assistanteverywhere or moving fully toagent. The terminology should describe one concept consistently.Proposed approach
Rename
assistanttoagentwherever the code, contracts, UI text, and documentation are describing Acolyte itself.Only keep legacy terminology where an external standard or unavoidable compatibility boundary requires it, and make that boundary explicit.
Scope