agent-service-toolkit: a LangGraph agent wired to FastAPI, Streamlit and the AG-UI protocol

The gap between a LangGraph script and a service someone else can call

Most LangGraph examples end at the point where the interesting work begins. A graph is defined, a model is bound, a tool is added, and the script prints a result. The next questions are unglamorous: how does a browser reach this, how do concurrent requests share one process, how does a conversation persist across page reloads, and what does the response look like on the wire. agent-service-toolkit exists to answer those questions with a runnable example instead of prose.

The README is direct about the intended audience: it is a template for building and running your own agents, demonstrating a complete setup from agent definition to user interface. The repository layout supports that claim. src/agents holds agent definitions, src/schema holds the protocol schema, src/core holds LLM definition and settings, src/service/service.py is the FastAPI service, src/client/client.py is the client, and src/streamlit_app.py is the chat interface. Someone who already knows LangGraph but has never shipped it behind an HTTP boundary is the person this is written for. Someone looking for a pip-installable framework with a versioned API should look elsewhere, because this is a starting point you fork and edit rather than a dependency you import.

Four processes, one schema, and where the bytes actually go

The data flow is linear and easy to trace from the file list. A Streamlit app calls the client in src/client/client.py. The client speaks HTTP to the FastAPI service in src/service/service.py, which invokes a LangGraph agent from src/agents. Responses come back the same way, and the schema module defines the shapes both ends agree on.

Two details in that chain matter more than the diagram suggests. The first is that agents are addressed by URL path: the README says an agent added to the agents dictionary in src/agents/agents.py can be called at /<your_agent_name>/invoke or /<your_agent_name>/stream. Routing is therefore a naming convention, and adding an agent means editing one dictionary rather than registering a route. The second is streaming. The README describes what it calls a novel approach supporting both token-based and message-based streaming, which is the distinction between partial text arriving as the model emits it and complete message objects arriving as graph nodes finish. Those are different client experiences, and the service is documented as serving both.

The service also exposes /info, which the README says describes available agents and models, and /threads, which lists a user's previous conversations per agent and backs the Previous Chats sidebar in the Streamlit app. Those two endpoints are the difference between a demo and something a returning user can use. AG-UI protocol support is layered on top: the README states that every agent is also served over the AG-UI protocol for frontends such as CopilotKit, with details in docs/AGUI.md. That means two protocol surfaces over one agent graph, which is convenient if you need a compatible frontend and extra surface area to maintain if you do not.

Getting it running: uv, a .env file, and docker compose watch

The README gives a Python path and a Docker path. The Python path starts by appending a key to .env, since at least one LLM API key is required:

echo 'OPENAI_API_KEY=your_openai_api_key' >> .env

It then recommends uv, installs it with the published shell script pinned to version 0.12.5, and notes that pip install . also works. The install and run sequence is:

uv sync --frozen source .venv/bin/activate python src/run_service.py

and, in a second shell, streamlit run src/streamlit_app.py. The Docker path is two commands: the same .env line, then docker compose watch. The README calls the Docker setup recommended for simpler environment setup and for reloading services when code changes, which is a reasonable default if you do not want to manage two shells and a virtual environment.

Configuration lives in .env, and the README points at .env.example for the full list. That list is wider than a single model key: provider API keys, header-based authentication, LangSmith tracing, testing and development modes, and an OpenWeatherMap key. Provider-specific setup has its own documents for Ollama, VertexAI and RAG with ChromaDB. Two smaller conventions are worth knowing before you commit code. File-based credentials belong in privatecredentials/, whose contents are ignored by git and by the Docker build process apart from .gitkeep files. And content moderation uses Safeguard, which the README says requires a Groq API key, so that feature is off unless you add a second provider.

The costs the README does not put in the feature list

Every feature in that list is a dependency you inherit. LangSmith tracing, star-based feedback, Safeguard moderation and ChromaDB RAG each bring their own configuration and their own failure modes, and the template ships them together. You can strip them, but stripping is work, and the tests in tests/ are written against the repository as it stands.

The more interesting limitation is version coupling. The README states that the agent implements LangGraph v1.0 features including human in the loop with interrupt(), flow control with Command, long-term memory with Store, and langgraph-supervisor. Those are the parts of LangGraph that have moved most between releases. A template that demonstrates them is only as useful as the version it was written against, and nothing in the supplied material gives a compatibility matrix or a statement of which LangGraph version is pinned. Treat the agent code as an example to read, not as an interface you can upgrade blindly.

There is also a boundary problem. The README describes header-based authentication as an environment variable, which suggests a single shared credential rather than per-user identity. The /threads endpoint lists a user's previous conversations, so the notion of a user exists somewhere in the schema, but the material does not describe how users are distinguished or isolated. If you need multi-tenant separation, that is the first thing to inspect in src/service/service.py and src/schema before building on top of it. Finally, the README notes that there are no releases retrieved, so there is no tagged version to pin against. You are tracking main.

What you would otherwise assemble yourself, and what that costs

The obvious alternative is to build the same four pieces directly: a LangGraph graph, a FastAPI app around it, a client module, and a Streamlit page. That is not difficult, and it is what most teams do. The difference is in the parts that are tedious rather than hard. Writing a streaming endpoint that handles both token-level and message-level output correctly is fiddly, and it is the kind of code that gets rewritten three times. Defining a schema that the client and the service both trust, and that survives an agent change, is the same kind of work. This repository has already made those choices and written tests around them, which is the actual product.

The other alternative is a hosted agent platform, where the service, the chat UI and the conversation store are someone else's problem. That trade is the reverse of this one: you give up control of the runtime and the data path in exchange for not maintaining them. The toolkit keeps everything in your process, which matters if the agent touches internal systems or if you need to run the model locally through Ollama. It also means you own the deployment, the scaling and the persistence, and nothing in the README suggests those are solved for you. Docker Compose is a development convenience here, not a production topology.

Maintenance surface and the MIT licence in practice

Because this is a template, upgrades are manual. There is no release to bump. When LangGraph changes the interrupt or Store APIs, you read the diff and edit src/agents yourself. The same applies to the AG-UI support, which is documented in docs/AGUI.md and depends on an external protocol specification. Two protocol surfaces over one agent means two places to check when something breaks.

The upside is that the maintenance surface is small and visible. The repository is Python, the schema is centralised in src/schema, and the service is one file. A team that has read those three locations can reason about the whole system. The testing story is also stated: the README describes unit and integration tests for the full repo, and the build badge points at a GitHub Actions workflow at .github/workflows/test.yml, so the shape of the test setup is inspectable before you adopt it.

On licensing, the repository is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive starting point, and it is the reason a template like this can be forked into a private product without a legal conversation. It does not resolve the licences of the dependencies you add or of the model providers you call, and it is not legal advice. If you ship the Streamlit app publicly, the feedback mechanism integrated with LangSmith is worth a second look, because user feedback leaving your infrastructure is a data question rather than a licence question.

Who should fork this, and what to check before the first commit

Fork it if you have a LangGraph agent in mind and you want the surrounding service, client and chat interface to exist already. The fastest way to judge fit is to run the two-command Docker path, open the Streamlit app, and then read src/service/service.py alongside src/schema. If the request and response shapes there look like something you can extend, the rest is editing agents.

Do not adopt it if you need a library with a stable version, if your users must be isolated from one another, or if you expect the repository to handle production concerns such as horizontal scaling and durable storage. None of that is claimed in the material, and the absence of releases means there is no version boundary to depend on.

Before writing your own agent, check three things in order. Confirm which LangGraph version your environment resolves to and whether the interrupt(), Command and Store examples in src/agents still behave as written. Confirm that /info and /threads return what you expect against your own service, since those endpoints carry the multi-agent and history behaviour. And decide whether you need the AG-UI path at all, because if your frontend is the included Streamlit app, docs/AGUI.md is surface you are maintaining for nobody.

Editorial conclusion

Adopt it if you want a LangGraph agent reachable over HTTP and chat within an afternoon, and you accept that the agent itself will be yours to write. Skip it if you need a packaged library, a stable API contract, or a deployment story beyond Docker Compose. Verify first that the interrupt and Store examples match the LangGraph version you pin, that /info and /threads behave as the README describes in your own service, and that the AG-UI path in docs/AGUI.md is something you actually need before you take on a second protocol surface.

Official sources

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