Purpose, inceptions, signals and limits
AgentPlat separates what an agent is trying to accomplish, what deserves attention, and what it is allowed to do. These are different decisions. This guide uses one support agent throughout: it investigates customer requests and prepares evidence-backed responses, with human approval before sending.
The concepts at a glance
| Concept | Question it answers | Support example |
|---|---|---|
| Purpose | What result should guide the agent's work? | Help resolve support requests with verifiable answers. |
| Inception | What input should be evaluated in relation to that purpose? | A customer reports an invoice problem in a Room message. |
| Signal | What observation deserves attention or reevaluation? | A request has been waiting for six hours. |
| Reference | How should an observation be interpreted? | The desired response window is four hours. |
| Limit | What must execution never exceed or bypass? | No refunds; approved tools only; human approval before sending. |
| Budget | How much of a controlled resource remains available? | The configured inference-spend allowance for this agent. |
| Mission | What bounded work will we undertake? | Check this invoice and prepare an evidenced response. |
| Outcome | What does the evidence show that work achieved? | The response is supported, or the unresolved case is escalated. |
Purpose: direction, not a standing permission
A purpose is the owner's stated intended result. It helps assess whether a proposed piece of work is relevant and how its outcome should be evaluated. It is broader than a task such as “summarize ticket 42.”
“Resolve support requests” does not authorize refunds, access to every customer record or sending messages. Identity, policies, execution controls and approvals still determine what is allowed. A broad purpose cannot override a narrow limit.
Purpose mode is explicitly selected on an immutable Agent Definition revision.
An existing definition without interaction stays instruction-driven. Both modes
can coexist; selecting purpose mode alone does not activate an agent or a scheduler.
See mode configuration and
adoption.
Inception: an input to consider
An inception is an attributed input submitted for assessment against the purpose. It can express a problem, suggestion or opportunity. In the current composition, intake refers to a message already persisted in an Agent Room; artifacts or external context can be referenced through that message.
For example, “This invoice appears to include a duplicate charge” is an inception. The assessor may adopt, reformulate or reject the proposed direction, or record another supported assessment disposition. The assessment retains explanation, uncertainty and evidence. Recording or adopting an inception does not authorize execution, and a suspended agent can retain inert intake records.
An inception is neither a new agent nor the whole governance system. It is also not a privileged instruction: source attribution is not proof of authority. See intake and assessment contracts.
Signals: observations that prompt evaluation
Signals provide quantitative, qualitative or event observations. Waiting time, an operator's quality assessment and a newly received reply are possible examples. They help decide whether work needs reevaluation; they are not action commands.
A signal has a defined source and retained observation context. Missing, stale or out-of-order observations must not silently be treated as fresh evidence. A host collector supplies observations; the host scheduler processes bounded evaluation wakeups. The library does not automatically poll every system or call an LLM.
An inception presents something to consider. A signal describes an observation that may change attention or interpretation. They may concern the same support case, but serve distinct roles and do not replace one another's records. See signals and wakeups.
References: interpretation, not enforcement
References provide the selected criteria for interpreting signals. If a waiting-time signal says “six hours” and the selected reference says “desired range: zero to four hours,” the observation deserves assessment. It does not grant permission to send a response or spend additional resources.
This is why a reference threshold is not a hard limit. “Prefer a response within four hours” is an interpretive target. “Do not send without approval” is an enforced execution restriction. The host must connect real controls for mandatory rules; putting a rule in prose or an interpretive reference does not implement enforcement.
Limits: the boundary of permitted execution
Limits constrain admitted work and effects: for example, which tools or operations are allowed and what execution bounds apply. Governed execution checks the current configuration and qualified adapter capabilities. Missing required controls must not be treated as available merely because an agent promises to obey.
Limits do not grant underlying permission. A permitted operation must also satisfy the application's authority and Action Gateway checks. Human approval remains a separate gate when required. Changing a purpose or selecting a different model cannot expand authority implicitly.
Budgets: cumulative resources and reservations
A budget tracks a controlled resource across work. A per-call limit and a cumulative budget are different: many individually small calls can exhaust a total allowance. AgentPlat reserves capacity before admitted effects and reconciles usage with trusted receipts. Hosts provide the relevant quotes and effect integration.
If a process fails after an external request, the result may be unknown. Failure does not prove that the provider did nothing: retain the reservation until trusted reconciliation establishes the outcome. Restarting or switching modes does not reset consumed budget. See execution and reconciliation.
Missions and outcomes: work and evidence
A mission translates an assessed direction into bounded, attributable work toward the purpose. It composes the existing Planner, Room tasks and outcome review. For this case: inspect the permitted invoice evidence and draft a response; escalate if the evidence is insufficient or the required action is outside authority.
Task completion is operational progress. It is not proof of purpose fulfillment. A generated response may still be unsupported, and a faster response-time metric may improve without resolving the customer's problem. Outcome assessment records what the evidence supports, including uncertainty, recovery or escalation. See mission lifecycle.
One case, end to end
- The owner sets the support purpose, selects references, sets limits and budgets, and prepares and activates a qualified execution profile.
- A persisted customer message is submitted as an inception for authorized assessment.
- A waiting-time signal creates a reason to reevaluate the case against its reference.
- Authorized assessment may lead to a bounded mission; intake and signals alone do not dispatch external actions.
- Work proceeds only while current authority, controls and budget permit it. Sending the draft still requires the application's human approval.
- Outcome review checks evidence. It may conclude that the request is resolved, needs more bounded work, or must be escalated.
The owner can suspend work or correct the configuration. Previously admitted uncertain effects still require reconciliation. Reactivation uses the current qualified profile, not a stale task's former permission. For restart and owner correction behavior, follow the support demonstration.
What the application must supply
AgentPlat provides contracts, persisted records and control composition. The host supplies authenticated identity, trustworthy observations, semantic assessors, scheduling and real effect controls. Jev is one optional assessor integration; these concepts do not depend on it. Neither a purpose nor publication of the library establishes model judgment quality or production-scale reliability.