Adam
Adam is the AI and agent experience built on Eve. It lets people and agents use models, databases, APIs, and tools through the same permissions, approvals, routing, and audit trail that Eve applies to direct API and gateway traffic.
Use Adam when the user experience is conversational, agentic, or workflow-driven, but the underlying systems still need governed access.
What Adam Does
Adam connects a user or agent session to Eve-managed resources:
User or agent
|
v
Adam conversation and tool runtime
|
v
Eve auth, RBAC, routing, policy, telemetry
|
+-- Models
+-- Endpoint tools
+-- Databases
+-- APIs and servicesAdam should not be treated as a separate security boundary. It uses Eve as the security and access boundary. If Eve does not grant a subject access to a resource, Adam should not expose that resource to the subject.
Core Capabilities
| Capability | Description |
|---|---|
| Multi-provider model access | Route model requests through Eve-managed model endpoints such as OpenAI, Anthropic, Ollama, or OpenRouter. |
| Governed endpoint access | Let users ask questions or run actions against endpoints without bypassing Eve permissions. |
| Tool discovery | Discover endpoint tools and expose them to the model with the right user context. |
| Tool orchestration | Let the model call tools, inspect results, and continue reasoning in the conversation. |
| Conversation persistence | Support long-running work as well as ephemeral sessions. |
| Token and cost accounting | Track usage by conversation, user, organization, and provider where configured. |
| Analytics and recommendations | Use traffic patterns to identify anti-patterns, risky behavior, and optimization opportunities. |
Tool Calling Model
The common Adam tool flow is:
- A user sends a chat request with references to endpoints, data, APIs, or tools.
- Adam resolves available tools through Eve-managed endpoint metadata.
- Adam sends relevant tool definitions to the model with the conversation context.
- The model decides whether to call a tool.
- Eve verifies that the user has the required access.
- The tool result returns to Adam and becomes part of the conversation.
- Telemetry records the model request, tool attempt, result, latency, and errors.
Keep tool definitions narrow. A tool that can mutate production data should require the same or stronger permissions as the direct API or database action it represents.
Access Rules
Adam follows these rules:
- A read-only user should only be able to read through Adam.
- An endpoint hidden from a user should not appear in Adam context.
- Robot and application identities should be scoped to the workflows they need.
- Tool calls should be auditable with user, organization, endpoint, tool, and model context.
- Sensitive output should be handled according to the same policy and telemetry controls used by Eve.
Operational Signals
Teams usually monitor:
- Model provider latency and error rate.
- Tool call attempts, failures, and duration.
- Token usage by provider, user, organization, and conversation.
- Rejected or unauthorized tool calls.
- PII detection, redaction, or policy outcomes.
- Endpoint hot spots such as repeated queries, hot keys, unbounded ranges, and high error rates.
When To Use Adam
Use Adam when:
- Operators need a governed assistant for production infrastructure.
- Application users need natural language access to data or tools.
- Agents need to call models and internal systems through one access path.
- You need a traceable audit trail for AI-assisted actions.
- You want recommendations from endpoint, model, and workflow telemetry.
Do not use Adam to bypass endpoint-specific controls. If a workflow requires direct database privileges, grant those privileges through Eve and let Adam inherit them.