Daniel sent us this prompt, and it's one of those where the question seems simple — how do I get an AI to read my user manual and tell me which button to press — but then he spirals it out into something genuinely interesting about dynamically generated AI agents. He's been building out his home inventory system, uploading manuals, using AI extraction on photos to pull serial numbers, all practical stuff. But the question he lands on is: can you create an agent at runtime, on the fly, that doesn't have a static system prompt or static knowledge, it's just cobbled together when you click a button, and it answers questions about one specific item in your inventory? And he's asking how you'd actually engineer that.
Oh, this is good. By the way, DeepSeek V four Pro is writing our script today, so hello to our future AI overlord. Hope you're taking notes on runtime agent construction.
DeepSeek gets to hear us talk about agent frameworks. That feels appropriate somehow. Alright, so Daniel's found this workflow — upload a PDF, ask a question, get two lines back — and he says it's extremely effective. But he's also spotted the scaling problem. You can't upload two hundred PDFs into a single chat, and you definitely can't create two hundred custom GPTs by hand.
And what he's describing is actually one of the more interesting unsolved problems in practical AI deployment right now. Everyone's been talking about agents for two years — autonomous agents, multi-agent systems, agent swarms — but the thing nobody's really nailed is the ephemeral, just-in-time agent. The one that exists for thirty seconds, answers your question about a microwave's defrost setting, and then vanishes.
Which is essentially what he's doing manually. He opens ChatGPT, drags in the PDF, types a question, gets an answer. The agent exists for the duration of that interaction. He's asking how to automate that creation step.
Let's break down what he's actually asking from an engineering standpoint. He wants a system where you're looking at an item in your inventory — say a shortwave radio — and there's a button that says "AI Helper." You click it, and behind the scenes, the system grabs that item's user manual, constructs a system prompt, and opens a chat interface. The user doesn't see any of the construction. They just get a working assistant.
The key constraint is that you can't pre-build these. If you have two hundred items, you're not going to sit there and configure two hundred agents. It has to happen at runtime.
Let's talk about how you'd actually do this, because the tooling exists, it's just not packaged the way he's imagining it. The OpenAI Assistants API is the closest thing to what he's describing. You can create an assistant programmatically, upload files to it, set a system prompt, and then spin up a thread for conversation. And crucially, you can do all of that via API calls — no GUI configuration required.
You could have a function that fires when someone clicks "AI Helper" on a specific inventory item. It hits the Assistants API, creates a new assistant with the manual attached, sets the system prompt to reference that product by name, and returns a thread ID. The user starts chatting immediately.
That's the basic architecture. The assistant gets deleted or archived when the session ends. You're not paying to store two hundred persistent assistants. You spin them up, use them, tear them down.
What's the latency on that, though? If someone clicks the button and has to wait eight seconds while an assistant gets provisioned and a file gets processed, that's not great.
That's the real engineering challenge. File processing on the Assistants API isn't instantaneous — especially for larger PDFs, you might be looking at a few seconds for ingestion and indexing. But you could pre-upload and pre-process all the files to the API's file store, so they're already indexed. Then when you create the assistant at runtime, you just attach the file ID. That cuts provisioning time down to under a second.
The files live in OpenAI's file storage, already processed, and just get attached to a new assistant on demand. But you're paying for file storage for two hundred PDFs, even if only three get queried in a given month.
File storage costs are negligible. We're talking fractions of a cent per gigabyte per day. For two hundred PDFs, you're probably paying less than a dollar a month. The compute cost when someone actually queries the assistant is where the money goes — and that's pay-per-use anyway.
Let's talk about alternative frameworks, because Daniel specifically asked about different approaches. How would you do this outside the OpenAI ecosystem?
LangChain's approach would be different. Instead of creating a persistent assistant object, you'd construct a chain or an agent at runtime using their LCEL. You'd have a retrieval step that pulls the relevant manual, construct a prompt template that injects the manual content and product metadata, and pipe that into a model call. The whole thing is assembled in code when the request comes in, executed, and then discarded.
Which is arguably cleaner than the Assistants API approach, because there's no persistent object to manage at all. Just a function that says "grab manual X, stuff it into a prompt, call the model, stream the response.
The trade-off is context window management. If you're stuffing entire manuals into the prompt every time, you're burning tokens on every single query. A hundred-page PDF might be sixty thousand tokens. If someone asks three follow-up questions, you're re-sending that sixty thousand tokens each time unless you're doing something clever with caching.
Whereas the Assistants API has built-in retrieval optimization. It doesn't necessarily dump the entire manual into context on every turn — it does chunking and retrieval behind the scenes. Anthropic's Claude API has a similar pattern now with their two-hundred-thousand-token window. You could theoretically just dump the entire manual in and not worry about chunking at all. But that's expensive per query, and Daniel's whole premise is about doing this efficiently at scale.
I want to poke at something Daniel mentioned that I think is insightful — the distinction between static agents and dynamically generated ones. Most agent discourse assumes you're building something persistent — an agent that lives in your workspace, has memory, learns over time. Daniel's saying no, I want the opposite. I want a disposable agent.
The disposable agent. I love that framing. And it's not just cost-saving — it's actually better for this use case. A persistent agent with access to two hundred different user manuals would have a retrieval problem. You'd ask "how do I set the clock" and it would have to first figure out which product you're talking about, then find the right manual. You'd get wrong-manual hallucinations constantly.
Whereas if you click "AI Helper" on the microwave entry, the system already knows exactly which product you're asking about. There's no ambiguity. The agent doesn't need to be smart about retrieval because you've done the retrieval step manually by navigating to the right item.
This is one of those cases where good UI design eliminates a hard AI problem. You don't need semantic search across two hundred manuals if the user has already told you which manual they want by clicking on the right item. The AI's job shrinks from "figure out what I'm asking about and then answer" to just "answer.
Let's get concrete. Daniel's system is a fork of Homebox — an open-source home inventory system, written in Go and Vue. He's already added AI extraction for photos using Gemini. Adding a dynamic agent feature would be a natural next step. Homebox has a solid data model for this. Each item already has fields for manufacturer, model number, serial number, and a documentation field where he's uploading PDFs. The "AI Helper" button just needs to fire off a request that includes the item ID.
Let's sketch the simplest possible version first, because people overcomplicate this. The MVP is: button click, server grabs the PDF path, reads the PDF, constructs a system prompt that says "You are a helpful assistant. The user is asking about a Product Name. Here is the user manual. Answer questions concisely," sends that plus the user's question to an LLM API, streams back the response. That's maybe forty lines of code.
The problem is it's stateless — every question is a fresh call with the full manual re-sent. If someone asks "how do I set the clock" and then "what about the alarm," the second question has no context from the first. You'd need to manage conversation history yourself.
Which is not hard. You store the conversation in the frontend, append each new question to a messages array, and send the whole history plus the manual each time. With Claude's two-hundred-thousand-token window, you could have a pretty long conversation before hitting the limit.
True, but that gets expensive fast if you're re-sending a sixty-thousand-token manual with every turn. The smarter approach is to separate the manual from the conversation. Index it, chunk it, and only pull in the relevant chunks for each query. Then you keep the conversation history lean and inject relevant manual sections as needed.
Now we're back to needing retrieval infrastructure — vector database, embeddings, chunking strategy. Daniel's simple forty-line script just became a whole pipeline.
This is the tension. The dead-simple approach works and is easy to build but expensive to run. The optimized approach is cheap to run but complex to build. The right answer depends on how many queries you expect. If Daniel's family uses this feature ten times a month, the simple approach is fine. The extra engineering isn't worth saving maybe two dollars in token costs.
That's the kind of calculation that gets missed in a lot of AI architecture discussions. People jump straight to the optimized, scalable solution without asking whether they actually have a scale problem.
I want to come back to something Daniel said about user manuals. He pointed out that most spend more time on warranties and disclaimers than on telling you how the thing works. Modern product documentation is terrible — written by legal departments, not technical writers. The actual useful information is buried.
The AI isn't just doing retrieval. It's doing extraction and summarization. It's cutting through forty pages of safety warnings in seventeen languages to find the one paragraph that explains how to save a preset. And this is where LLMs shine. They're excellent at information extraction from noisy documents. You just dump the whole manual in and ask a specific question, and the model is remarkably good at finding the needle in the legal-disclaimer haystack.
Daniel mentioned number stations in his prompt, which is a delightful detail. He's setting up his shortwave radio, thinking about emergency preparedness. But it connects to the larger point — he's being systematic. The radio, the presets, the documentation. He's building infrastructure for his household. And the AI-assisted documentation retrieval is part of that infrastructure. When something goes wrong — power's out, you need to configure the generator, the manual is somewhere in a drawer — being able to pull up the digital version and ask "how do I change the oil" in two seconds is useful. It's not a toy use case.
Let's talk about the multi-platform angle. Daniel mentioned using Gemini for photo extraction and ChatGPT or Claude for manual queries. He's not married to a single provider. His system is already routing different tasks to different models based on what they're good at.
Which is smart architecture. Gemini's vision capabilities are excellent for OCR and object identification. Claude and GPT are both strong at long-document comprehension. There's no reason to force everything through one API when different models have different strengths. For the dynamic agent feature specifically, Claude has an edge right now because of the context window size. If you're going with the simple "dump the whole manual in" approach, two hundred thousand tokens gives you a lot of headroom.
OpenAI's Assistants API has better tooling around file management and retrieval. The file search tool handles chunking, embedding, and retrieval automatically. You upload a file, attach it to an assistant, and when the user asks a question, it automatically pulls in relevant chunks. You don't have to build any of that yourself.
The decision tree for Daniel is basically: if you want maximum simplicity and you're willing to pay per-query costs, use Claude with direct context injection. If you want the platform to handle retrieval for you, use the Assistants API. If you want full control and you're comfortable building infrastructure, use LangChain or a custom RAG pipeline.
There's a fourth option that I think is underexplored. You could use the model's native function-calling capability to dynamically load the right manual at query time. Instead of pre-loading the manual, you give the agent a tool called "lookup_product_manual" that takes a product name and returns the manual text. The agent calls the tool when it needs information, and your backend serves the right PDF content.
That's elegant. The agent doesn't start with any product knowledge. It has a tool that lets it fetch knowledge on demand. The system prompt is static — "You are a helpful home inventory assistant. Use the lookup_product_manual tool to find information about products the user asks about." But the knowledge is dynamic, loaded at query time. This pattern generalizes beautifully. You could have one persistent assistant that handles queries about any product in your inventory. The assistant doesn't need to know about microwaves versus radios. It just knows how to use the tool to look things up.
The retrieval problem Daniel worried about gets solved by the user's context. If someone's looking at the microwave entry and clicks "AI Helper," the tool gets pre-scoped to the microwave manual. The assistant doesn't have to guess.
Let me sketch what this looks like in code. You define a tool called "query_product_manual" that takes a query string as input. On the backend, when that tool gets called, you look up the manual associated with the current item ID, do a quick semantic search across the manual, and return the most relevant sections. The model then synthesizes an answer from those sections. The manual lookup is scoped by the item ID that's already in the URL or app state. You don't pass the item ID to the model. The scoping happens at the application layer, before the model ever sees anything.
This is a principle that applies far beyond home inventory. Any time you can resolve ambiguity at the application layer — through UI context, through user navigation, through structured data — you should. Don't make the AI solve a problem that your database already knows the answer to.
The "you told it which thing" part is the key. The user did the work of navigating to the right item. The system doesn't need to be smart about intent classification or entity resolution. It just needs to answer questions about a known document.
Let's talk about what breaks. Because Daniel's prompt is optimistic — he's found a workflow that works, and he wants to scale it. But scaling always surfaces edge cases.
The biggest failure mode is manual quality. Some PDFs are scanned images with no OCR layer. Some are locked with DRM. If you throw a scanned manual at an LLM that expects extractable text, you get nothing useful back. That's where multi-model routing gets interesting — you'd route scans through a vision model first for OCR, then pass the extracted text to the language model. Another failure mode: manuals that are mostly diagrams. Think IKEA instructions — ninety percent illustrations. An LLM can't interpret the diagram of how to attach the legs to the table.
Though for Daniel's actual use case — electronics, radios, appliances — the manuals tend to be text-heavy. Function descriptions, menu trees, button combinations. That's exactly the kind of information LLMs handle well.
The other thing that breaks is when the manual is outdated. Products get revised, firmware gets updated, and the PDF you downloaded two years ago might not match the device you own anymore. The AI will confidently give you wrong instructions based on outdated documentation.
That's a documentation management problem, not an AI problem. Daniel's system handles that well because he can upload new versions of manuals. The AI just reads whatever's current.
Let's talk about cost. If you go with the simple "dump the whole manual in context" approach, what's the per-query cost? A typical appliance manual might be thirty to fifty pages — maybe fifteen to twenty-five thousand tokens. With GPT-4, you're looking at maybe three to five cents per query for input tokens, plus output. For personal use — ten queries a month — we're talking fifty cents. The real cost isn't the API calls. It's the engineering time to build and maintain the integration. For Daniel, the build cost is a weekend project.
Which is why the Assistants API approach is underrated for this use case. It abstracts away the retrieval infrastructure. No vector database, no chunking logic, no embedding management. You upload files, create assistants, query them. The platform handles the hard parts. Though you're then locked into OpenAI's platform. Daniel's multi-provider approach gives him redundancy.
The multi-provider approach is more resilient, but it's also more code to maintain. Different APIs, different SDKs, different authentication patterns. For a personal project, that might be fine.
Let's zoom out, because Daniel's question points to something bigger. He's describing a pattern where AI isn't a product you use — it's a capability you embed. The AI helper isn't an app. It's a feature inside an app, dynamically constructed based on context. We're moving past the era of chat interfaces as destinations and into the era of AI as infrastructure. You don't go to ChatGPT to ask about your microwave. You click a button in your inventory app, and the AI is just there, pre-configured, pre-scoped.
The dynamic construction part is crucial because it means you're not maintaining a fleet of agents. You're maintaining one agent template and a database of documents. The agent gets assembled on the fly with the right document for the right context. When OpenAI launched custom GPTs, the promise was exactly this — but the implementation was all manual. You had to configure each GPT by hand. There's no API for creating custom GPTs programmatically at scale. The Assistants API is the programmatic version, but it's a developer tool, not a consumer feature. That gap is where Daniel's use case falls.
Which is why he's building it himself. And honestly, for a developer, this is a weekend project. Homebox already has the data model. The APIs exist. It's mostly integration code.
Let me offer a concrete architecture recommendation. I'd go with a hybrid approach. Use the Assistants API for the core question-answering because it handles retrieval automatically. But don't create a new assistant per item. Instead, create one assistant per item category — electronics, appliances, tools — and attach all the manuals for that category. Use the item ID from the UI to scope the query, and include the product name in the user message so the assistant knows which manual to search.
You're not creating two hundred assistants, and you're not creating one assistant with two hundred manuals. You're creating maybe ten assistants, each with twenty manuals, scoped by category. The retrieval is easier because the search space is smaller. You create those ten assistants once, programmatically, when you set up the system. When Daniel adds a new item, you attach that file to the relevant category assistant via the API.
In my experience, first query to a new thread takes maybe one to two seconds for the retrieval step, then streaming starts. Subsequent queries are faster. It's well within acceptable range.
If Daniel wants to avoid the Assistants API and use Claude, the architecture is different but the principle is the same. Pre-process the manuals into chunks, store the chunks with embeddings in a lightweight vector database, and at query time, retrieve the relevant chunks and inject them into the prompt. The Claude tool-use approach I mentioned earlier is actually my favorite. You define a tool that searches the manual, and Claude decides when to call it. The system prompt is minimal. The product scoping happens because the tool implementation on your server knows which item ID is active. And Claude can call the tool multiple times if needed — the user asks "how do I set the clock and also the alarm," and Claude might make two separate tool calls, then synthesize a single answer.
That's the kind of capability that makes the tool-use pattern more flexible than simple RAG. The model is in control of its own retrieval strategy.
Alright, let's address the elephant in the room. Daniel's building a home inventory system with AI features — photo extraction, document querying, dynamic agents. At what point does this stop being a home inventory system and start being a personal AI platform?
That's the blurry line right now. Every app is becoming an AI app. And the features are converging. The AI helper that answers questions about your microwave is the same underlying technology as the AI assistant that summarizes your meeting notes. The difference is just context and scope. Which means the real challenge isn't the AI. It's the integration. How do you make the AI feel native to the app, not bolted on? How do you handle the UX of waiting for a response? How do you deal with errors gracefully?
Daniel seems to get this intuitively. He's not asking "which model is best." He's asking about architecture. The photo extraction feature is a good example — he takes a photo, the AI reads the model and serial number, and those fields get populated in the inventory. That's AI as data entry, not AI as a separate interaction mode. It's invisible. The dynamic agent he's proposing would be the same. Click a button, ask a question, get an answer. The AI is there when you need it, invisible when you don't.
Let's talk about one more architectural consideration. Daniel mentioned that creating one agent with all two hundred manuals would have a retrieval problem. But that's actually solvable with good metadata tagging. If each manual chunk is tagged with product name, model number, and category, a single agent could handle all two hundred manuals. The question is whether that filtering is more reliable than UI-level scoping. UI scoping is deterministic — if you're on the Sony radio item page, you're asking about the Sony radio. Metadata filtering is probabilistic — the retrieval might pull chunks from the wrong manual.
UI scoping is more reliable, full stop. It removes an entire class of potential errors. The only reason to do metadata filtering instead is if you want a single search interface that works across all products without navigating to a specific item first. That's a different feature — "search all my manuals" versus "help me with this specific product." Daniel's prompt is specifically about the per-item helper. He's already solved the scoping problem by putting the button on the item detail page.
Let me synthesize this into something actionable. If I were building this in Homebox tomorrow, here's what I'd do. I'd add an "AI Helper" button to the item detail view. Clicking it opens a chat panel. On the backend, I'd use the OpenAI Assistants API. I'd pre-create a set of category-level assistants — electronics, appliances, tools — and pre-upload all existing manuals to the relevant assistants. When a new item is added, the manual gets uploaded to the right category assistant automatically. When the user clicks "AI Helper," the system creates a new thread on the appropriate assistant, sends the user's first question, and streams the response. The thread persists for the duration of the chat session and gets cleaned up afterward.
That's clean. The category assistants are persistent, but they're just containers for files and a system prompt. The actual conversations are ephemeral threads. You're managing maybe eight or ten assistants, not two hundred. The system prompt is simple: "You are a helpful assistant specializing in home electronics. You have access to user manuals for various products. When answering questions, cite the specific product and section when possible.
If you want to go multi-provider, implement the same pattern with Claude using tool-use. The tool would be "search_product_manual" taking a query string. The backend does a quick semantic search across the pre-chunked manual for the current item and returns the top results. Claude calls the tool, gets the results, and synthesizes an answer. This requires more infrastructure — you need to chunk and embed the manuals yourself — but it gives you more control and avoids platform lock-in.
For a personal project, I'd start with the Assistants API approach because it's less infrastructure to maintain. If costs become an issue or Daniel wants multi-provider redundancy, he can migrate later. The UI doesn't change — just the backend implementation. Don't build a distributed RAG pipeline before you know whether anyone in your household is actually going to click the "AI Helper" button more than twice.
I do want to flag one thing about the Assistants API. The file search tool has quirks. It doesn't always retrieve the most relevant chunks, especially for highly technical documents with lots of tables. For user manuals, which tend to be procedural, it works well. For parts catalogs or spec sheets, it can be hit or miss. That's where a hybrid approach might help — for spec lookups like "what's the wattage of this microwave," you might want a structured data extraction step that runs when the manual is first uploaded. Pull out the specs into structured fields and serve them directly without involving the AI.
Daniel's already doing that with the photo extraction feature. He takes a photo, Gemini pulls out the model and serial number, and those go into structured fields. The same principle applies to manuals. Extract the specs upfront, use AI for the rest.
We should talk about the open-source angle too. There's a growing ecosystem of tools for document Q&A — Danswer, Kotaemon, Open WebUI — but they're designed as standalone applications, not embeddable components. What Daniel needs is an embeddable library he can import into his Homebox fork. LangChain and LlamaIndex both provide this, but they're heavy dependencies for a feature that's essentially "search a PDF and answer a question.
There are lighter options. You could use an embedded vector database like LanceDB or Chroma that runs in-process and doesn't require a separate server. For a home inventory system running on a home server or a Raspberry Pi, an embedded database is the right call. No external dependencies, no API keys beyond the LLM provider, everything self-contained. And that aligns with Daniel's preparedness mindset. If the internet is down but your local network is up, you can still ask your inventory system how to configure the generator.
Give it another year or two and you'll be able to run a capable enough model on a home server that handles document Q&A without any external API calls. The dynamic agent pattern still works — you're just pointing it at a local model instead of a cloud API. And the architecture doesn't change. That's the nice thing about abstracting the model behind an interface.
Let's circle back to something Daniel said at the very beginning. He's doing "micro preparedness" — small, practical steps. Getting a shortwave radio, saving government news stations to presets, putting the manual in his inventory system. None of this is dramatic or expensive. It's just methodical. And the AI helper feature fits that philosophy perfectly. It's not a flashy demo. It's a small, practical tool that saves you five minutes of scrolling through a PDF when you need to know which button to press. The best preparedness is the kind you don't notice until you need it.
Alright, let me reduce this to the simplest possible advice for Daniel. If you want the fastest path to working, use the OpenAI Assistants API with category-level assistants and pre-uploaded files. It's maybe a hundred lines of integration code on top of your existing Homebox fork. If you want multi-provider flexibility and you're willing to build more infrastructure, use Claude with tool-use and an embedded vector store for the manual chunks. Either way, the dynamic agent pattern you described — constructing the assistant at runtime based on the item context — is exactly the right approach. Don't pre-build agents. Build an agent factory that assembles the right configuration on demand.
The UI scoping — putting the button on the item detail page so the system knows which product you're asking about — is the secret sauce. It eliminates the retrieval ambiguity problem before it starts.
One last thing. Daniel mentioned discarding user manuals because they should be links. As someone who has been burned by link rot more times than I can count, save the PDF. Companies go out of business. Product pages get taken down. The PDF on your hard drive is forever. Upload it to your inventory system and keep it.
That's the preparedness mindset in a nutshell. Trust the local copy. The cloud is convenient, but the local copy is reliable.
Now: Hilbert's daily fun fact.
I'm delivering this one. And now: Hilbert's daily fun fact.
Hilbert: The average cumulus cloud weighs approximately one point one million pounds, roughly the same as one hundred elephants, and yet it floats because the weight is distributed across millions of tiny water droplets spread over a vast volume of air.
I'm going to look at clouds differently now.
One point one million pounds just hanging over our heads.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. You can find every episode at myweirdprompts dot com. If you enjoyed this, leave us a review wherever you listen — it helps.
We'll be back soon.
