Where to go next

The app is live. Every block of the architecture diagram from the start of the tutorial is implemented. A full-stack app with auth and persistent chat, a document ingestion pipeline, hybrid agentic retrieval, grounding with enforced citations, and a deployment serving it all on public URLs. This page closes the tutorial by putting that in perspective and giving you the roadmap for what comes after.

daveebbelaar/document-copilot3:34:00

What you built

Walk the diagram once more, because everything on it now exists in the repo:

• Data model defined in Python with SQLAlchemy and synced to hosted Supabase through Alembic migrations, with RLS keeping each analyst's chats private.
• A monorepo with strict agent files, so AI tooling can move between backend and frontend with full context.
• An ingestion pipeline that parses SEC filings with Docling, plus a custom HTML table extractor when Docling's tables fell short, feeding chunks with both vector embeddings and full-text search vectors.
• A PydanticAI agent that reasons in a loop over search_filings, read_chunk, and read_surrounding_chunks, with a grounding validator that fails closed when a citation does not map to a retrieved passage.
• A streaming chat UI with clickable citations and source passages, deployed as two Railway services.

Dave's point about the career value is worth repeating. Most engineers live in one vertical (frontend, backend, data, DevOps) and few know how the pieces tie together. If you followed along and can show this as a portfolio project, and more importantly explain it, that full-stack capability is rare.

This is only just the beginning

The honest framing is that a four-hour video is a speedrun. When Datalumina takes on a client solution like this, the first phase alone is planned at about two weeks, and that is just a solid proof of concept. Every purple building block on the diagram deserves at least a full day of real validation, and in this build each one got a short plan and an agent told to go work on it.

Concretely, nobody has validated the prompts or the tools yet. The agent implemented more than expected (the tool set, the retrieval behavior), and the system instructions have not had a single word reviewed or optimized. Those files are the core of how the solution behaves, and understanding them is now your job, not the agent's.

The iteration roadmap

Real users will hit this first. Say "Hey there, what can you help me with?" and the agent dutifully searches the filings, takes its time, and cites sources for a greeting. The current setup trades speed and cost for grounded answers on every query, which is the right default for analyst questions and the wrong one for small talk. These are the fixes, in rough order:

• Tune the agent instructions so simple questions get answered directly instead of triggering the full search loop.
• Add a query classification step before retrieval that decides whether the query is a deep analytical question needing the whole pipeline, a quick question answerable from the system prompt, or a follow-up about something already retrieved.
• Build more focused search tools for follow-ups, so a question about one detail in a previous answer does not rerun the entire search.
• Reconsider the model. A grounded agentic loop on a frontier model can easily cost one to two dollars per query. A cheaper, faster model gives up some quality, and that trade has to fit the business case you calculate for the client.

Speed, cost, and accuracy form a triangle you will tune on every project. There is no single right answer, only the right answer for these users.

Harden before real client data

The deployed app currently has a plain email and password login and a public backend. Handle these before any real client documents go in:

• Add stronger authentication such as SSO (for example Google sign-in), or at minimum two-factor authentication.
• Lock down FastAPI's /docs, which exposes your full endpoint surface to anyone with the URL.
• Run recurring security checks to confirm every endpoint is properly protected as the app evolves.

Rebuild it with your own data

Dave's strongest recommendation is to start fresh with a new dataset. He has no interest in analyzing these annual reports, which means he cannot judge whether an answer is actually right, and neither can you if the domain means nothing to you. Find a dataset you know well, or better, a person with a real problem, so that the real test becomes possible. Ask a question, read the answer, and fact-check it.

Then go deep on the internals. Look at the chunks in the database (this build accidentally ingested some documents multiple times, which is exactly the kind of thing you find by looking). Read the table extraction logic and verify it. Open the prompts and the tools and ask AI "how does this work," then keep asking "explain it simpler" until you understand it from first principles. That is the only way to do this work professionally and get paid for it over the long run.

The actual AI engineering starts here. And it pays for itself in an unexpected way. If you understand your stack, using AI tools is as straightforward as asking a question. No elaborate agentic setups required, just good questions from someone who knows what they are looking at.

Keep going