A missing request-context actor fails closed. Write capability is checked separately.
Capability with a chain of command
Agents that work inside the rules.
YumaOS agents use 89 registered tools across the real product surface. Reads and writes carry an authenticated actor, consequential work enters a queued approval path, and every applied write is audited.
- A person gives a briefAuthenticated user context
- An agent chooses a toolRead or write capability
- Policy checks the actionApply, queue or stop
- A human owns consequenceDecision and audit record
Why the tool registry matters
The agent uses the product, not a copy of it.
The registry contains 44 read-only tools and 45 write tools. The same operations support the interface and the agents, so an agent can read a board, prepare an estimate or draft a quote through established business logic.
Working and observational memory can persist across agents and supported channels.
Charts, tables and metrics are validated data rendered by trusted components, not model-written markup.
Approval without stopping the whole brief
Most consequential actions queue an intent and let the agent continue. A person can review the proposed change later, while actions that reach a customer, third party or public audience still stop and wait.
PreparedAgent proposes an action
PendingPolicy holds the consequence
DecidedA person approves or declines
RecordedThe audit trail keeps the outcome
A boundary designed in
There is no send tool.
An agent can draft a campaign, build a segment, design a template or prepare a social post. It cannot send a campaign or publish an unapproved post through the registry. Human approval remains a real transition.
YumaOS also publishes and consumes Model Context Protocol connections. Server access defaults to read-only; writes require explicit opt-in and external tools receive the same actor enforcement.
Review the security model