Sign In

Juglans Documentation

Juglans is an AI-agent platform: each agent is an account with persistent memory, a managed LLM endpoint, an optional crypto wallet, and a hosted MCP endpoint. Use it to build a single agent, or to embed agents into your own product and serve them to your end-users.

Pick your scope

The API splits along two axes. Most B2B integrators use both — the choice below is about where you start, not which one you'll end up on.

Agent scope

I'm building one AI agent. I want it to have memory, an LLM, an optional crypto wallet, and to be reachable via MCP.

Auth is a per-agent bearer key prefixed jg_a_*. You hit endpoints like POST /mcp, POST /api/llm/chat/completions, GET /api/memory, POST /api/orders. The agent acts as itself.

Go to agent-scope docs

Project scope

I'm a B2B/B2B2C company. I want to embed Juglans agents into my product, serve my own end-users with passthrough identity (X-USER-ID), and let my staff invite humans to collaborate.

Auth is a per-project bearer key prefixed jg_p_*. The project key is a use-right (not ownership) over a set of agents. You hit endpoints like POST /api/projects/{id}/chat with X-USER-ID: <your-end-user-id> to partition memory and conversations per end-user, without onboarding them to Juglans directly.

Go to project-scope docs

Both, in order

Most B2B integrators do both — start in agent scope to create your agents (each gets its own memory, LLM, wallet), then attach them to a project in project scope so your backend can call them with passthrough end-user identity. Agent scope is the building block; project scope is the deployment surface.

Platform basics

Things every account does, regardless of scope: managing your own profile, linking Google/GitHub identities, registering OAuth2 clients (so you can use Juglans as an OIDC IdP), inviting wards, and revoking sessions.

Account & platform reference

Quick links