--- title: Use Cases description: The two most common use cases for eve are business agents that work for your own company and agents you ship to customers as a product. url: "https://eve.dev/docs/use-cases" docs_index: /llms.txt --- > For an index of all documentation, see [/llms.txt](/llms.txt). eve gives you everything you need for production agents. The two most common use cases for eve are business agents that work for your own company and agents you ship to customers as a product. - **[Business agents](#business-agents)** (For your team): Automate a company function, like analytics, a software factory, marketing, or finance. - **[Agent as a Service (AaaS)](#agent-as-a-service-aaas)** (For your customers): Build multi-tenant agentic applications that scale as you grow. ## Business agents A business agent takes on work for teams inside your company. The most common are software factories that plan, build, and review code alongside engineers, and company brains that answer employees' questions from internal data. Employees reach the agent in Slack, Microsoft Teams, or GitHub, and it acts on the company's own systems and data. - **Software factory**: Agents plan features, open pull requests, review code, and respond to incidents alongside an engineering team. See the [Software Factory template](/templates/eve-software-factory-template). - **Company brain**: One agent holds the company's skills, tools, and approved connections, reachable where employees work, with each employee's own identity and connections. See the [Company Brain template](/templates/eve-company-brain-template). - **Marketing team**: A lead agent routes work to specialists for positioning, long-form content, social, SEO, and email, then publishes through Notion, Typefully, and Resend. See the [Marketing team template](/templates/marketing-team-eve-template). ### How eve supports business agents An eve agent lives in [your repository](/docs/concepts/project-structure), so it is reviewed, deployed, and governed like the rest of your stack. - **Meet employees where they work**: One agent serves Slack, Microsoft Teams, GitHub, Linear, and your own web apps, with a session for every conversation. See [Channels](/docs/channels/overview). - **Govern and audit every run**: OpenTelemetry traces and Agent Runs record every session, model call, and tool call, so you can see what an agent did and why. See [Observability](/docs/observability/instrumentation). - **Use your identity provider**: Verify callers with any OIDC issuer, JWTs, or your own authenticator. Each connection then acts as the agent itself or on behalf of the signed-in user. See [Identity and access](/docs/guides/auth-and-route-protection). - **Switch models without a code rewrite**: Changing models is a one-line edit in agent.ts, and requests can fall back to another provider on failure. See [Models](/docs/agent-config). - **Connect to approved services**: Expose the MCP and OpenAPI services your IT team approves. Credentials stay in the runtime, and the model never sees them. See [Connections](/docs/connections). - **Evaluate agent responses**: Evals are automated tests that run the agent through real turns and score the result with code checks or a model judge, so you catch regressions when a prompt, tool, or model changes. See [Evals](/docs/evals/overview). - **Put deterministic steps in the loop**: Tools are typed TypeScript functions the model chooses when to call. When a process must run the same way every time, use a workflow tool instead. Its code fixes the order of steps, calls subagents exactly where you say, and waits durably for approvals or webhooks between steps. See [Workflow tools](/docs/tools/workflows). - **Run commands in sandboxed compute**: Each session gets an isolated filesystem and shell for scripts, repositories, and generated files. See [Sandbox](/docs/sandbox). - **Keep a human in the loop**: Sessions pause while an approval is pending and resume durably when it resolves. A decision model can auto-approve routine tool calls. See [Human-in-the-loop](/docs/human-in-the-loop). ## Agent as a Service (AaaS) In AaaS, the agent is the product. One multi-tenant deployment serves many customers, and each of them trusts it with their work over long stretches of time. It has to serve every user durably and keep each tenant's data and identity separate from the next. - **Web chat**: A Next.js chat app with sign-in, persisted conversations, and long-term memory for each user. See the [Web Chat Agent template](/templates/eve-chat-template). - **iMessage agent**: A multi-tenant iMessage service with user accounts, scoped memory, an encrypted vault, and cloud browser automation. See the [iMessage template](/templates/openinstinct-eve-template). - **Voice agent**: Users talk to the agent in the browser while it runs tools, asks for approvals, and keeps durable state. See the [Voice Agent template](/templates/eve-voice-template). ### How eve supports AaaS Each end user gets their own [sessions](/docs/concepts/sessions-runs-and-streaming) and connections, running on the same agent project you deploy once. - **Isolate every tenant**: Bind memory, connection credentials, and approval policy to the authenticated tenant and user, so one customer's data and access never reach another. See [Multi-tenancy](/docs/patterns/multi-tenant-auth). - **Customize the agent per tenant**: Resolve the model, tools, connections, skills, and instructions at runtime from the caller, their tenant, or a feature flag, all from one deployment. See [Dynamic capabilities](/docs/guides/dynamic-capabilities). - **Run work on fixed and dynamic schedules**: Fixed cron schedules power digests and monitors with no user present. Experimental dynamic schedules let users and agents create their own recurring or one-time runs at runtime. See [Schedules](/docs/schedules). - **Trace latency and every tool call**: Traces and Agent Runs show per-turn latency and the tool calls behind each response. See [Observability](/docs/observability/agent-runs). - **Route each request to the right model**: Pick models per user, tenant, or feature, or let a decision model choose from your allowlist automatically, to balance cost, latency, and quality. See [Model selection](/docs/guides/decide). - **Keep long-running sessions durable**: Each user's session checkpoints every step, parks while it waits, and resumes on the next message, even days later. See [Durable sessions](/docs/concepts/execution-model-and-durability). - **Keep long-term memory for each user**: Each user gets their own long-term memory of preferences and facts. It carries across sessions, stays isolated from other users, and lives in the provider you choose. See [Memory](/docs/memory). - **Act on behalf of each user**: Connections authenticate to services like GitHub and Linear with each user's own grant, so tools call them without managing tokens. See [User-scoped connections](/docs/connections). - **Run untrusted input in isolation**: Each session processes user data in its own sandbox. Subagents take work that needs its own prompt, tools, or sandbox. See [Sandbox and subagents](/docs/sandbox). ## Start building Create an agent and open the terminal UI. ```bash npx eve@latest init my-agent ``` --- For a semantic overview of all documentation, see [/sitemap.md](/sitemap.md) For an index of all available documentation, see [/llms.txt](/llms.txt) For agent-facing discovery, including API and MCP surfaces, see [/agents.md](/agents.md)