django-ai-assistant: wiring Django methods into an LLM tool loop
Integrate AI Assistants with Django to build intelligent applications
At a glance
- What is it?
- django-ai-assistant 0.4.0 is a Django app that registers model methods as tools an LLM can call, plus retrieval over your own data. It is a good fit for Python teams already on Django 4.2 or 5.x who want tool calling without hand-rolling the plumbing, and a poor fit for anyone who wants a managed, no-code assistant.
- Who is it for?
- Adopt it if you have a Django project on 4.2 or 5.x and want tool calling and retrieval without building the message loop yourself; the example project under example/ shows the intended shape of a real assistant. Do not adopt it if you are not on Django, if you need a stable API surface, or if you expect the README to be the documentation, since it points to a separate docs site instead.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 176 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: LLMs cannot touch your Django models
A chat completion endpoint is easy to stand up and nearly useless on its own. The model can write text about an order, but it cannot look up that order, check whether it shipped, or cancel it. Closing that gap normally means writing a tool schema, parsing the model's tool call, dispatching to a Python function, serializing the result back into the message history, and looping until the model stops asking for tools. That loop is where most of the incidental complexity lives, and it is the same loop in every project.
django-ai-assistant targets that layer. The README states the goal plainly: "Let AI Assistants call methods from Django's side and do anything your users need." The intended audience is a Django developer who already has models, views and business logic, and who wants an assistant that can reach into them. The package description in pyproject.toml calls it a "Django app to integrate with OpenAI Assistants API", though the dependency list shows the provider layer is now LangChain-based, with langchain-openai, langchain-anthropic and langchain-google-genai all listed as optional extras. That description lags the code.
How the tool loop and RAG fit together
The architecture visible in the repository is a Django app plus a LangChain and LangGraph runtime. pyproject.toml pins langchain ^1.2.6, langgraph ^1.0.6, pydantic ^2.9.2 and django-ninja ^1.5.3. Pydantic is doing schema work, django-ninja is the API surface, and LangGraph is the agent runtime that drives the call-answer-call cycle.
Providers are separated into extras. The base install pulls no model SDK. You opt into langchain-openai, langchain-anthropic or langchain-google-genai as an extra, which keeps the dependency tree smaller if you only ever talk to one vendor. The .env.example at the repository root contains a single line, OPENAI_API_KEY=your-key-here, which tells you the default path is OpenAI and that credentials come from the environment rather than a settings module.
Retrieval is a separate concern from tool calling, and the example directory reflects that split. example/rag/ sits alongside example/issue_tracker/, example/movies/, example/tour_guide/ and example/weather/. Each of those looks like a demo of one capability rather than one monolithic sample app, which is a reasonable way to document a framework, though it means there is no single end-to-end reference application to copy.
Installing django-ai-assistant and running a first assistant
The project is a Poetry package, and pyproject.toml declares python ^3.10 and Django >=4.2. The extras are named in the [tool.poetry.extras] table; openai maps to langchain-openai. The top-level README does not carry install commands of its own, so the documentation site is the reference for the assistant registration API.
Credentials come from the environment. The repository root ships .env.example with exactly one variable, so copy it and fill in a real key before anything will run. Its full content is:
OPENAI_API_KEY=your-key-hereThe repository root has a manage.py and an example/ directory with its own manage.py, settings and frontend build files (package.json, pnpm-lock.yaml, webpack.config.js, tsconfig.json). The example app is the fastest way to see a working assistant rather than reading API signatures: example/README.md is the entry point, and the demo, weather, movies, rag, tour_guide and issue_tracker subdirectories each exercise a different capability. The README also links a five minute demo video and the documentation at vintasoftware.github.io/django-ai-assistant. Note that the README does not include a quickstart of its own, so budget time for the docs site before you can register your first assistant.
Where django-ai-assistant stops being the right tool
The classifier in pyproject.toml is Development Status :: 3 - Alpha, and the release history backs that up: 0.2.1 in January 2026, 0.3.0 in March, 0.4.0 in March. Three releases in the 0.x line with a minor bump between 0.3.0 and 0.4.0 means you should expect breaking changes between minor versions. If you need an API you can pin for two years without reading a migration guide, this is not that.
The second limitation is provider coupling. The optional extras are the three LangChain integrations listed, and the root .env.example only anticipates OPENAI_API_KEY. Anything outside that set means writing your own integration against the LangChain interfaces, and the README does not document how to do that.
The third is that this is a framework, not a product. There is no hosted control plane, no evaluation dashboard, no prompt versioning in the repository layout. You get a Django app and a set of conventions. Teams that want to configure an assistant in a browser and never touch Python are looking at the wrong category of tool entirely.
Finally, the README is thin by design. It carries badges, a demo video link, a Discord invite, contributing notes and a commercial support contact, but no API walkthrough. All of that lives at the documentation URL. If your evaluation process is "read the README and decide", you will not have enough to decide with.
Against hand-rolled LangChain glue and against Django-native chat widgets
The obvious alternative is doing it yourself: add langchain and langgraph to your project and write the tool dispatch, persistence and API layer. That is a real option, and the difference is not capability, because django-ai-assistant is built on those same libraries. The difference is that you inherit a Django app with migrations, settings conventions and an example project showing the intended structure. If your assistant is one endpoint with two tools, the framework is overhead; if you have several assistants sharing tool definitions and history, the conventions start paying for themselves.
The other alternative is a Django chat package that wraps a model behind a view and streams tokens to a template. Those solve the display problem. They do not solve the tool calling problem, and the moment a user asks the assistant to actually change something in your database, you are back to writing the dispatch loop. The two are not really substitutes, and picking the wrong one shows up late, when the assistant needs its first write action.
Maintenance, versioning and the MIT licence
django-ai-assistant is MIT licensed, with LICENSE.txt at the repository root and the MIT classifier declared in pyproject.toml. That permits commercial use and modification, and the package description names Vinta Software as the author. The README has a commercial support section pointing at contact@vinta.com.br, which is a normal arrangement for an agency-maintained open source project: the licence is permissive, but the maintenance roadmap is set by the maintainer's priorities.
The last push to the default branch was on 2026-03-23, the same day 0.4.0 was released. That is roughly six months before the current date, so it is fair to describe the project as released and documented rather than continuously churning. Version 0.4.0 is the current release, and the changelog is published at the documentation site under /latest/changelog rather than in the repository root, although CHANGELOG.md does exist in the tree.
Upgrade cost is the practical concern. Because the dependencies are pinned as caret ranges on langchain, langgraph and pydantic, a fresh install six months from now will resolve to newer transitive versions than the ones 0.4.0 was tested against. The tox.ini and .pre-commit-config.yaml in the repository suggest the maintainers run a test matrix, but nothing in the repository layout says the package pins its LangChain dependencies to exact versions for consumers. Budget time for that.
Editorial conclusion
Adopt it if you have a Django project on 4.2 or 5.x and want tool calling and retrieval without building the message loop yourself; the example project under example/ shows the intended shape of a real assistant. Do not adopt it if you are not on Django, if you need a stable API surface, or if you expect the README to be the documentation, since it points to a separate docs site instead. Before committing, check the version pinning in pyproject.toml against your own Django and Python versions, confirm which provider extra you need, and read the changelog for the 0.3.0 to 0.4.0 window, because the classifier still reads Development Status :: 3 - Alpha.
Frequently asked questions
What is django-ai-assistant used for?
It is a Django app for building AI assistants that can call methods on the Django side, so the model can read and act on your own application data. The README also lists AI Tool Calling and RAG as the two capabilities it supports.
Which Python and Django versions does django-ai-assistant support?
pyproject.toml declares python ^3.10 and Django >=4.2, with classifiers for Python 3.10 through 3.13 and Django 4.2, 5.0 and 5.1. Anything older than Django 4.2 is outside the declared range.
Does django-ai-assistant only work with OpenAI?
No. The base install includes no model SDK, and pyproject.toml defines optional extras for langchain-openai, langchain-anthropic and langchain-google-genai. The root .env.example only shows OPENAI_API_KEY, so other providers are less documented.
Is django-ai-assistant stable enough for production?
Its own classifier reads Development Status :: 3 - Alpha, and the release history shows 0.2.1, 0.3.0 and 0.4.0 within the first three months of 2026. Expect breaking changes between minor versions and pin accordingly.
How do I install django-ai-assistant?
It is distributed as a Poetry package named django-ai-assistant, with optional extras such as openai that map to langchain-openai. The README itself does not carry install steps; it points to the documentation site at vintasoftware.github.io/django-ai-assistant.
Where can I see a working django-ai-assistant example?
The repository includes an example/ directory with its own manage.py and subdirectories for demo, weather, movies, rag, tour_guide and issue_tracker. example/README.md is the place to start.
Community notes