Agent Service Toolkit: the LangGraph agent, its FastAPI server and its chat face

Four pieces, one template

The project bundles everything a working agent service needs in four parts, a LangGraph agent, a FastAPI service to serve it, a client to interact with the service, and a Streamlit app that uses the client to provide a chat interface, with data structures and settings built on Pydantic throughout. The repository layout mirrors that decomposition, src/agents holding several agents with different capabilities, src/schema defining the protocol schema, src/core carrying the LLM definition and settings, src/service/service.py the FastAPI layer, src/client/client.py the client, and src/streamlit_app.py the interface. The positioning is honest, a template demonstrating a complete setup from agent definition to user interface, with a video walkthrough of the repository and app, and a live demo deployed at agent-service-toolkit.streamlit.app. The quickstart shows the two run paths concretely, the uv route,

# At least one LLM API key is required
echo 'OPENAI_API_KEY=your_openai_api_key' >> .env

# uv is the recommended way to install agent-service-toolkit, but "pip install ." also works
# For uv installation options, see: https://docs.astral.sh/uv/getting-started/installation/
curl -LsSf https://astral.sh/uv/0.12.5/install.sh | sh

# Install dependencies. "uv sync" creates .venv automatically
uv sync --frozen
source .venv/bin/activate
python src/run_service.py

# In another shell
source .venv/bin/activate
streamlit run src/streamlit_app.py

and the Docker route reduced to an env line and docker compose watch.

LangGraph v1.0 features, demonstrated

The included agent is built to showcase the current LangGraph generation, implementing the v1.0 features rather than legacy patterns, human in the loop through interrupt(), flow control with Command, long-term memory with Store, and multi agent orchestration with langgraph-supervisor. That framing matters for a template, since these are the mechanisms a production agent actually needs, pausing for approval, steering execution, remembering across sessions, delegating to sub agents, and seeing them wired together in working code answers the question documentation alone cannot. The customization path is documented in three steps, add a new agent to src/agents by copying research_assistant.py or chatbot.py, register it in the agents dictionary in agents.py, and adjust the Streamlit interface to match its capabilities.

Two streaming granularities, and AG-UI on top

The FastAPI service serves the agent with both streaming and non-streaming endpoints, and the streaming implementation claims a novel approach supporting both token-based and message-based streaming, the two granularities frontends actually want, raw tokens for typing effects and complete messages for structured rendering. Beyond its own protocol, every agent is also served over the AG-UI protocol for connecting AG-UI compatible frontends like CopilotKit, documented in a dedicated file, which turns the service into a standard component rather than a bespoke API. The Streamlit interface itself goes past text, including voice input and output, and the asynchronous design with async and await across the service keeps concurrent requests from serializing behind one another.

Multiple agents, addressed by URL path

One service can host several agents, called by URL path, with the available agents and models described through the /info endpoint, so a deployment exposes a catalog rather than a single hardwired assistant. Each registered agent answers at its own name, /your_agent_name/invoke for non-streaming calls and /your_agent_name/stream for streaming, the routing convention that makes the agents dictionary the service's deployment table. Conversation history is a first class feature, a user's previous conversations listed per agent via /threads and surfaced as a Previous Chats sidebar in the Streamlit app, and a star-based feedback system integrates with LangSmith, closing the loop from usage to evaluation that agent teams otherwise bolt on later.

Postgres, SQLite or Mongo for checkpoints

State persistence is pluggable at the dependency level, with langgraph checkpoint savers for Postgres, SQLite and MongoDB all present in the project's dependencies, and the environment selecting between them through DATABASE_TYPE, postgres mode taking the full POSTGRES_ connection variables and sqlite mode an optional SQLITE_DB_PATH. The docker compose file stands up the Postgres side concretely, a postgres:16 service with a health check, the agent service waiting for it to be healthy before starting, and its own health check polling /info. Development ergonomics come from compose watch, syncing and restarting the agent, schema, service, core and memory directories when source changes, immediate reloading being the stated reason Docker is the recommended setup. Connection pool sizing is even exposed through environment variables, with saver and store pools configured independently.

The .env surface and the AUTH_SECRET warning

The environment template maps the provider landscape in one file, API keys for OpenAI, Azure OpenAI, DeepSeek, Anthropic, Google, Groq and OpenRouter, a Bedrock toggle, Vertex credentials and an AWS knowledge base id, plus an openai-compatible escape hatch of COMPATIBLE_MODEL, COMPATIBLE_API_KEY and COMPATIBLE_BASE_URL for any unlisted provider, and USE_FAKE_MODEL for testing without spending tokens. Web configuration covers HOST and PORT defaulting to 8080, a MODE of dev enabling uvicorn reload, and LangSmith tracing toggles. The line that deserves respect is AUTH_SECRET, HTTP bearer token authentication is required if set, and the warning is explicit, if unset all API endpoints are unauthenticated, always set this in production, the kind of note written after someone learned it the hard way.

From Ollama to vLLM, with RAG and moderation

Provider reach extends past the API key list through dedicated guides, setting up Ollama for local models, running local models on local hardware with vLLM or SGLang, configuring VertexAI, and standing up the included RAG agent with ChromaDB. That RAG agent is a documented example, not an aspiration, and content moderation arrives via Safeguard, requiring a Groq API key. The dependency list shows the breadth in code, the langchain bindings for Anthropic, AWS, Google, Groq, Ollama, OpenAI and Chroma, MCP adapters, langfuse beside langsmith for observation, document ingestion through pypdf and docx2txt, DuckDuckGo search, and even an OpenWeatherMap client. There are no GitHub releases, the master branch is the distribution, last pushed 2026-09-25, under MIT with Python 3.12 through 3.14 and a full unit and integration test suite in tests.

Editorial conclusion

Start from this toolkit when a LangGraph agent needs to become a real service, an API, a UI, history, feedback, checkpointed state, containerized, rather than staying a notebook, since the template's value is exactly the production scaffolding around the agent. It is heavier than a bare LangGraph script, so skip it for experiments that will never serve traffic. Before deploying, set AUTH_SECRET, the environment template warns that unset means every endpoint is unauthenticated, pick the checkpoint database matching your infrastructure, and copy research_assistant.py or chatbot.py as the documented path for your own agent rather than writing one from scratch.

Frequently asked questions

Official sources

1. Issues
2. JoshuaC215/agent-service-toolkit on GitHub
3. License: MIT
4. Project website
5. README