Docling

Sunday Coffee & Code: Successful End-to-End RFP Generation Run (Web UI + Multi-Agent Orchestration) This week I got a clean end-to-end run of my RFP Factory: upload through the Web UI, multi-agent orchestration does the heavy lifting, and a complete draft package comes out the other side. It’s one thing to have individual components working; it feels like a whole other step to have the whole pipeline behave like a real system. What worked (and why it matters) ● Multi-Agent Orchestration (Microsoft Agent Framework - MAF) MAF performed exceptionally well as the orchestration layer - both for offline Model (Ollama) and OpenAI integration with tool execution. The “agent team” approach is now predictable enough that it feels like engineering, not experimentation. ● Local models via Ollama (Qwen3 continues to impress) Even though this run used OpenAI’s API end-to-end, it reinforced that local models are not just “nice demos.” The Qwen3 family in particular performed strongly for this workflow. ● MCP (Docling via MCP: surprisingly frictionless) Docling via MCP has been one of the simplest pieces to integrate: download it, start it, expose it as a tool to agents, and it just works. That’s exactly what “tooling” should feel like - boring, reliable, repeatable. ● Agentic coding (Anthropic Claude Code from VSCode + Agent) This was a major step-change. Not just “faster coding", it changes the way I worked. I spent more time on the specification and acceptance criteria up front. Troubleshooting does shift a bit: being more “distant from the code” can mean it takes longer to reacquire context when something breaks. Experience matters here: knowing where to look (configs, log files) helps. What I’ve learned building this (beyond the RFP use case). This project has been a practical vehicle for exploring a stack of emerging patterns and technologies - and it’s clarified a few things for me: ● Agents have matured dramatically since my first builds in 2024. Reliability, tool use, and orchestration patterns are materially better now. ● Specs are the new leverage. The better the spec, the more “agentic coding” compounds across quality and speed. Not entirely sure what is next yet - this has been a bit of a wander, but in the best way: exploring new tech with a practical application in mind. Likely next steps: ● Improve RAG setup (talked about this a few times). ● Automate startup and deployment. ● Add agents to further improve the workflow. ● Build this out as a solution? Cost snapshot (because this part matters) - today’s run: ● 407,743 tokens for $1.45. ● 16.5 minutes of Amazon Web Services (AWS) server time. ● Total of $1.70 for a draft. If you’re experimenting with agents, MCP, or multi-agent orchestration, I’m happy to compare notes - this space is moving quickly, and the practical details are where the learning is. (Lots of screen shots attached - front-end, log file, agent activity logs, output zip file contents attached.)

Quarkus Insights #323: What is Docling? Michele Dolfi, Thomas Vitale, and Eric Deandrea join us to discuss Docling, a project which converts documents into structured data for AI models. Learn how it parses various file types, such as PDFs, DOCX, and images, to extract rich information like layout, tables, and reading order, making documents suitable for generative AI applications like Retrieval-Augmented Generation (RAG) systems and how to use it with Quarkus.

Sunday Coffee & Code: RAG improvements, and a few detours Most of my recent Coffee & Code time has been going into one very specific thing, improving the RAG layer behind my Microsoft Agent Framework–based RFP multi-agent solution. Here’s the path so far. Step 1: Chroma + Docling (via MCP) ● This was the first “real” implementation. Simple vector search over RFP input, fed by Docling. ● It worked well enough to support one live RFP response, which is an MVP bar for me - whether something is more than an experiment. Step 2: LightRAG ● I then went looking for ways to improve retrieval quality and came across LightRAG (https://lnkd.in/gCftxBBr), which combines vector search, knowledge graph, and re-ranking. ● Technically, it was impressive. I got it running, built the knowledge graph, and the architecture made a lot of sense. ● But it also did something unsettling: the knowledge graph started containing things that were never in the source documents (for example, “Noah Carter – World Athletics Championship”). Whether this was a hallucinated artifact or not, it was a reminder to take a closer look. Step 3: OpenRAG Last week I came across IBM's OpenRAG stack - https://www.openr.ag/ - (Langflow + Docling + OpenSearch Project) and it checked a lot of boxes for me: ● LangFlow (where I built my first real agent back in 2024) ● Docling (already central to my document pipeline) ● OpenSearch (scalable, production-grade search) ● Langfuse support (observability - also used it before and it provides valuable insights) The install was quick (Docker, Inc based), though I did hit a startup issue on my Amazon Web Services (AWS) EC2 instance that took some fiddling to resolve (GitHub issue - https://lnkd.in/g38qb8QK - fixed with my PR: https://lnkd.in/g594VTQ6). Once running, though, this stack is genuinely interesting: configurable models, Langfuse tracing, and full access to LangFlow flows sitting right under the RAG layer. This feels much closer to something I could operate, tune, and trust over time (as well as getting support for). Next steps: Now it’s about stabilising the OpenRAG deployment and wiring it cleanly into my RAG Manager so the agent can start using it for real RFP work. As always, this about exploring the latest tools as well as answering a simple consulting question: Can I use this in a real, production, workflow and trust it? More to come.