Admin controls
Approved context
Trust & Boundaries
The person configuring an agent, the user working in its dedicated workspace, and a website visitor need different levels of access. AgentShelf treats them as separate operating contexts and helps evaluators inspect the controls supported for each experience.
Operating contexts
Admin controls
Approved context
Website visitors
Scoped answers
Different actors. Different access.
A platform user may configure instructions, knowledge, tools, model behavior, and limits. A website visitor should receive only the public experience prepared for that surface.
How the contexts relate
The platform user configures the agent, approved resources, deployment settings, model behavior, and applicable controls.
The authenticated user works with the focused agent, its context, tools, conversations, results, and available activity.
A public or embedded experience receives only the settings and capabilities prepared for that surface. It does not expose the private management experience.
A visitor or application interacts through the interface prepared for that experience.
Available model, usage, event, error, and result information can return to the platform for review.
Configuration, access checks, records, retention, and behavior depend on the implemented interface and deployment.
What to evaluate
Which user, agent, workspace, widget, or application owns the configuration and request?
Which session and origin checks apply to this public or embedded experience?
Which information and capabilities are available on this surface?
Which validation, throttling, limits, and model behavior govern the experience?
Which events, errors, model details, usage, cost, and results are available?
What is retained, what depends on customer configuration, and who responds when the workflow fails?
Walk through the controls, dedicated workspace, public or embedded session, permitted tools, and available records.