Adam
Adam is the AI and agent product built on Eve for governed AI work against endpoints. It gives each licensed human user, agent, or gateway API key an Eden LLM interface and tool-calling runtime for using 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, model-driven, or workflow-driven, and the AI needs governed access to Eve endpoints. Eve can govern a model provider as an endpoint; Adam governs the AI experience that uses models and endpoint tools together.
Seat and API-key entitlements are governed by the applicable Eden license. The docs describe the product and API surfaces; the license defines commercial counting and pricing.
What Adam Does
Adam connects a licensed user, agent, or gateway API-key session to Eve-managed resources:
Licensed user, agent, or gateway API key
|
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.
Adam should also not be treated as a generic endpoint gateway. Eve owns endpoint onboarding, credentials, native protocol access, VPN placement, templates, APIs, workflows, endpoint RBAC, and shared masking or PII controls. Adam owns the governed AI layer that lets users and agents ask questions, call tools, summarize data, and run workflows against those endpoints.
Core Capabilities
| Capability | Description |
|---|---|
| Seat and API-key governance | Attribute AI usage to licensed human users, agents, or gateway API keys according to the applicable Eden license. |
| Multi-provider model access | Route model requests through Eve-managed model endpoints such as OpenAI, Anthropic, Ollama, or OpenRouter. |
| Model route control | Change model providers, deployments, route aliases, prompts, structured output, and per-request overrides through Eve-managed configuration. |
| Orchestration modes | Run requests as single-pass conversations, tool loops, reviewed plans, or orchestrated multi-agent task graphs. |
| Governed endpoint access | Let users ask questions, summarize data, or run actions against endpoints without bypassing Eve permissions. |
| Shared data protection | Apply Adam LLM PII scanning, template lookup, content policies, and access boundaries to AI traffic, alongside Eve endpoint masking where an endpoint route supports it. |
| 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.
Model Routing And Orchestration
Adam model behavior is configurable through Eve-managed model endpoints and route aliases. Operators can change which provider or deployment backs a route, which system prompt or assistant profile applies, which tools are available, whether structured output is required, and whether the request should run directly, through a tool loop, through a reviewed plan, or through full orchestration.
This keeps model choice out of application code. A team can move a route from a low-latency model to a deeper reasoning model, send private workloads to a local endpoint, or force orchestration for multi-step operational work while preserving the same endpoint permissions, approvals, telemetry, and audit trail.
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.
- Agent and application identities should be scoped to the workflows they need.
- Model requests should be attributable to a licensed user, agent, or gateway API key.
- 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.
AI Governance
Adam governance applies reusable controls before model provider, saved template, or tool egress. Operators can combine Eve's shared PII and masking controls with content policy profiles, policy bindings, access boundaries, feature audit, and promptless governance records.
Use Adam when an AI workflow needs to summarize sensitive documents, assist internal research, run operations agents, or call internal tools against Eve endpoints without bypassing endpoint permissions or exposing raw sensitive values to model providers or unapproved resources.
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.