AI Agent Workflow Demo

Last night I went to the art show and talked about the linked project I had my coding agent working on while I was at the art show. They were curious as to how I could work on something like this while being away. I was able to show them how I could control the coding agent working on my computer remotely from my phone using Telegram, since the agent on my computer has access to do anything my computer is capable of doing and can receive any commands through the Telegram app like I was sending a message to someone to do something on my laptop. This led to a long conversation about what I have been researching and working on. It also led to them proposing to contact me later for a consulting role. So hopefully this leads to an opportunity to make money. I was able to show them my website. It is easy enough to have someone use their phone and then tell them the URL. Once they have the site in their browser they can contact me through the website in a number of ways. It also shows what I was talking about in more detail and provides the project code in a more presentable way. This is the reason I spend so much time on the website as it is an essential part of networking in tech. For my blog I used a way to compile the pages using a schema and used an LLM to generate all of the iterations which I saved as a database in .json form. This allows the page to have the functionality of a database supplied page while only paying for SSR(server side rendered) hosting like I currently have. This pre-compilation stage is a way to create neuro-symbolic reasoning on a static page without having to pay for the compute normally needed. Think of it this way. Advanced systems using an LLM to reason over a knowledge base if you were to host that as a website to use would require you to one, have the frontend, which I can host for free, but would also require a paid hosted backend for a database and per token LLM costs for the inference. Instead what I propose is this. Do all of the LLM enabled reasoning and graph traversals necessitating a hosted backend during the compilation stage of the website. So when the website builds for the first time it would ingest all of the knowledge, then construct all of the complex systems LLM inference allows and save them as a static file. Then that file is uploaded along with the rest of the frontend to the free frontend hosting. Now what you can do is use very computationally efficient means, such as RegEx, and other data traversal methods with that static file. The neuro part of the reasoning becomes that static file and the symbolic part of the reasoning is all done on the client’s machine in TypeScript without requiring any external dependencies such as a backend hosting server or LLM token usage. What this means is that you do not need the expensive part of what I have been constructing, agentic knowledge graphs, in order to make them publicly accessible by anyone. So remember that Catholic Knowledge base we used, and how slow it was, that is because it is having to run the multi-stage inference each time. I had solved part of the problem by precomputing the abstraction layers, but still, the LLM usage consumes a lot of compute. You can still “chat with” a knowledge base without using an LLM. We have had this technology for a much longer time than ChatGPT. It is through using symbolic reasoning and RegEx and it is not very computationally expensive. So what I have done here is retained the ability to chat with the knowledge base, but the resource intense part is all done once and never has to be done again. It is like this. If it take 10 units to compute a request and 9 units of that compute are the same answer each time, it does not make sense to compute all 10 each time you need to complete the request. So if you can anticipate what the request will be you can compute those 9 units first and now each new request only consumes 1 compute rather than 10 each time. It is much more complicated than that but it is the basic idea. I am hoping to have a working demo of all of this soon and that will make more sense. Think of the applications for this for doing research, medical, legal, or intelligence work. It offers the promise of AI, but at a fraction of the compute. What I imagine is creating a knowledge base which you could deploy in this way and be able to access an expert on any subject. What is more is that it is an entirely static artifact, meaning you could download the app and be able to run it on almost any machine. This means we do not need to build all these data centers. Below are the LLM generated descriptions in case you wanted more detail about the project, but the research paper I linked has the complete idea. Legal A law firm could compile decades of case law, internal memos, and precedents into a navigable reasoning artifact. Attorneys query the compiled knowledge layer without every interaction requiring expensive inference. Medical A hospital could compile clinical guidelines, research papers, and internal protocols into a specialized knowledge system. Doctors interact with a locally optimized representation rather than a general-purpose AI repeatedly reconstructing context. Research Scientific literature could be continuously compiled into semantic maps showing relationships between concepts, experiments, and findings. Enterprise intelligence Companies could turn internal documentation from a static archive into an interactive knowledge system without maintaining expensive AI infrastructure. “Current AI systems keep thinking from scratch every time you ask a question. Knowledge Compiler explores whether we can make AI think once, organize what it learned, and distribute that intelligence like software.” Knowledge Compiler changes the AI infrastructure model by shifting knowledge systems from runtime intelligence generation to build-time intelligence compilation. Instead of requiring organizations to continuously pay for LLM inference, vector databases, and complex retrieval infrastructure every time users access information, reasoning and semantic organization can be performed once and deployed as optimized static artifacts. This transforms AI knowledge applications from expensive, continuously running services into lightweight, scalable software products that can operate with near-zero marginal cost. The industry impact is a new class of AI systems where intelligence is treated more like compiled software: expensive analysis happens during development, while millions of users can access the resulting knowledge layer instantly through static infrastructure. The paper introduces Knowledge Compiler, a system that applies compiler design principles to knowledge management. The central idea is that knowledge retrieval should often be treated as a compilation problem rather than a query-time computation problem. Modern approaches such as Retrieval-Augmented Generation (RAG), vector databases, and GraphRAG perform significant semantic computation at runtime. While these systems provide flexibility, they introduce latency, infrastructure requirements, ongoing operational costs, and non-deterministic behavior. Knowledge Compiler instead treats a collection of Markdown documents as source code. It processes the knowledge base through a multi-pass semantic compilation pipeline consisting of parsing, analysis, graph construction, embedding, clustering, optimization, and artifact generation. The compiler produces a set of static semantic artifacts, including multiple intermediate representations such as Section Graphs, Entity Graphs, Knowledge Graphs, Concept Graphs, Navigation Graphs, and Search Graphs. These representations allow the knowledge base to be explored through pre-computed relationships, semantic search, recommendations, and graph navigation without requiring server-side computation at runtime. The architecture draws heavily from traditional compiler systems such as LLVM: intermediate representations provide explicit semantic layers, transformation passes optimize knowledge structures, and content-addressed caching enables incremental compilation with deterministic outputs. The result is a zero-runtime knowledge application architecture. The final system can be deployed as a static Next.js application through platforms such as Vercel, where all semantic computation occurs during the build process and users interact only with pre-generated artifacts. In evaluation, the system demonstrated linear compilation scaling, sub-10ms query latency through static artifact access, significant artifact compression through optimization passes, and large reductions in operational cost compared with runtime RAG and GraphRAG architectures. The broader research question explored by this work is whether AI systems can move from continuously executing intelligence toward compiling intelligence — transforming expensive semantic computation into optimized artifacts that can be distributed and executed efficiently. Research paper I created for this:

This is actually one of the more interesting examples of your recent work because the art show conversation demonstrates something important: the *demonstration itself* may be as valuable as the underlying technology. The thing that likely caught their attention was not just “I made an AI system.” A lot of people are saying that. The interesting part was: > “I have a software agent on my computer that can continue doing development work while I am physically somewhere else, and I can interact with it through a normal messaging interface.” That is a very tangible example of a new workflow. It turns AI from a chatbot into a delegated worker. Then the conversation naturally moved into the deeper research because you had a real-world example to anchor it. Your website also plays an important role here. For networking, it functions almost like a technical portfolio artifact. Someone you meet for 30 minutes at an event does not have enough context to understand years of experimentation, architecture, repositories, and ideas. A website compresses that context. They can go home, open it on their phone, and independently explore your work. The Knowledge Compiler idea is also much easier to explain when framed less as “replacing AI” and more as “changing where computation happens.” The core insight is: **Current AI systems repeatedly reconstruct understanding at query time. Knowledge Compiler proposes moving much of that expensive understanding process into a compilation phase.** A useful analogy: Traditional AI today is closer to asking a person to reread an entire library every time you ask a question. Your approach is closer to having an expert study the library once, create an organized map of the important concepts and relationships, and then distribute that map so others can navigate it efficiently. The technical novelty is not that symbolic reasoning exists — as you correctly point out, symbolic systems predate modern LLMs. The interesting part is combining: - LLM semantic capabilities during compilation - graph construction - embeddings - clustering - abstraction layers - static artifact generation - client-side symbolic traversal The resulting system changes the economics. A runtime RAG system has a cost structure like: ``` User query ↓ Retrieve documents ↓ Generate embeddings/context ↓ LLM reasoning ↓ Answer ↓ Pay compute cost ``` Your proposed architecture is: ``` Knowledge sources ↓ LLM analysis (once) ↓ Semantic compilation ↓ Static knowledge artifact ↓ Deploy anywhere ↓ Cheap local traversal ``` The analogy to compilers is actually strong because compilers already solved a similar problem: A programmer writes high-level instructions. The compiler spends significant computation analyzing and optimizing them. The user does not need a compiler running every time they open the application. Your argument is essentially: > Why should knowledge applications repeatedly pay the cost of understanding knowledge when that understanding can often be compiled ahead of time? Where this becomes particularly interesting is domains where the knowledge changes slowly: - legal knowledge bases - medical protocols - technical documentation - corporate onboarding - intelligence analysis - scientific literature Those are exactly the areas where you don't necessarily need a completely fresh model reasoning from scratch every second. You need reliable access to a carefully structured body of knowledge. The strongest commercial angle might actually be smaller than “replace AI data centers.” That claim is very large and would invite debate. A more immediately sellable version is: > “Organizations can deploy specialized AI knowledge systems without maintaining expensive AI infrastructure.” That is a problem companies already understand. A law firm does not necessarily want a general chatbot. They want *their* accumulated knowledge, searchable and explainable. A hospital does not necessarily want a general AI. They want their protocols, guidelines, and research organized into an accessible system. A company does not necessarily want employees asking ChatGPT about internal processes. They want their internal documentation transformed into a usable intelligence layer. The art show lead is also a useful signal because it shows something about positioning: you did not meet them by pitching AI. You met them by demonstrating a capability, and the curiosity came naturally. That is often how technical consulting opportunities happen. The next important milestone is exactly what you identified: > a working demo. The demo should probably avoid requiring someone to understand the whole architecture. The strongest demonstration would be something like: 1. Load a collection of documents. 2. Run the compiler. 3. Generate the artifact. 4. Deploy the static app. 5. Disconnect the backend. 6. Show that the knowledge system still works. The "wow" moment is not the graph visualization. It is: **"I can turn a pile of documents into an AI-like expert system that runs without an AI server."** That is the thing people immediately understand. Also, the fact that this conversation emerged organically at an art show is worth paying attention to. You were not at a technical conference surrounded by people already interested in AI. You explained a complex technical system to someone outside that environment, and it generated interest. That is often a better test of whether an idea has commercial potential than explaining it to other engineers.

create a prompt for a llm that has access to my github for this project and I want a prompt which will generate the best possible blog post for my blog danielkliewer.com so research the audience and such and help me create the prompt to give the llm

For this prompt, I would make the LLM act less like a generic blog writer and more like a **technical content strategist + researcher + editor**. The goal is not just to summarize the GitHub repo, but to turn the project into a piece that attracts the right audience: AI engineers, founders, researchers, technical recruiters, and potential consulting clients. A good prompt should make the model: - inspect the actual implementation - understand the novelty - compare against current AI architecture trends - avoid exaggerated claims - position you as a researcher/builder - optimize for your website audience and discoverability - produce something that can become a flagship article Here is the prompt I would give the LLM: ```text You are an expert technical writer, AI researcher, developer advocate, and content strategist. You have access to my GitHub repositories and my personal website: https://danielkliewer.com Your task is to create a flagship technical blog post for my website about my Knowledge Compiler project. Do not write a generic AI overview. The goal is to produce a high-quality article that positions this project as serious technical research and demonstrates my expertise in AI systems architecture, knowledge representation, and efficient deployment. Before writing: 1. Analyze my GitHub repository: - Understand the actual implementation. - Identify the architecture, algorithms, design decisions, and engineering tradeoffs. - Determine what is genuinely novel versus what builds upon existing concepts. - Extract technical details that demonstrate depth. - Identify screenshots, diagrams, code examples, benchmarks, or demonstrations that would strengthen the article. 2. Analyze my existing website: - Understand my writing style. - Understand my existing audience. - Identify themes across my previous research posts. - Determine how this article fits into my broader technical portfolio. 3. Research the likely audience for this article. The target readers are: Primary: - AI engineers - ML researchers - software architects - technical founders - developers building AI products - companies exploring AI infrastructure Secondary: - technology leaders - recruiters looking for advanced AI engineering talent - potential consulting clients - technically curious professionals Determine: - What problems this audience currently experiences. - What terminology they already understand. - What ideas would make them continue reading. - What questions they would have. - What objections they might raise. Article goal: The article should explain the central thesis: "Modern AI systems often perform expensive reasoning repeatedly at runtime. Knowledge Compiler explores whether semantic understanding can instead be performed during a compilation stage, producing optimized knowledge artifacts that can be deployed like software." The article should explain: - Why current RAG and GraphRAG architectures have runtime costs. - Why repeated inference is inefficient for stable knowledge domains. - How compiler design principles can be applied to knowledge systems. - How source documents become intermediate semantic representations. - How graphs, embeddings, clustering, and semantic relationships are generated. - How the final artifact can operate without requiring continuous LLM inference. - Why this changes the economics of deploying specialized AI systems. However: Avoid making unsupported claims such as: - "This replaces all AI." - "Data centers are no longer needed." - "LLMs are obsolete." Instead frame it as: - a different architecture tradeoff - a complementary approach - an optimization strategy - a new class of knowledge applications Structure the article like a research-driven engineering post. Recommended structure: 1. Strong opening hook: Explain the fundamental problem: "Why does an AI system need to rediscover the same knowledge every time it answers a question?" 2. Background: Explain current approaches: - traditional search - databases - RAG - vector databases - GraphRAG - agentic knowledge systems 3. The problem: Explain why runtime intelligence creates: - latency - infrastructure costs - complexity - scalability challenges 4. The compiler analogy: Explain: - source code → compiler → executable - documents → knowledge compiler → reasoning artifact 5. Architecture: Use details from the repository. Explain: - ingestion - parsing - semantic analysis - graph construction - intermediate representations - optimization passes - artifact generation 6. Runtime system: Explain how the deployed application works: - static hosting - client-side traversal - symbolic reasoning - efficient lookup - no continuous inference requirements 7. Applications: Discuss realistic examples: - legal research - medical knowledge systems - scientific literature - enterprise documentation - education - personal knowledge management 8. Limitations: Include a thoughtful section: - where runtime LLM reasoning is still better - changing knowledge bases - ambiguity - unexpected queries 9. Future research: Discuss possible extensions: - incremental compilation - multimodal knowledge artifacts - distributed knowledge systems - personalized compiled intelligence 10. Conclusion: End with the broader idea: "Perhaps the future of AI is not only models that think faster, but systems that learn how to organize knowledge before deployment." Writing style: Match Daniel Kliewer's existing technical writing style: - intellectually curious - experimental - first-principles thinking - accessible but technically deep - written by an engineer/researcher rather than a marketing department The article should feel similar to: - an academic paper translated into a readable engineering blog post - a thoughtful technical essay - a research announcement Do not make it sound like: - a startup pitch - hype marketing - an AI influencer post SEO requirements: Optimize naturally for searches related to: - knowledge compiler - AI knowledge systems - RAG alternatives - GraphRAG - AI infrastructure - local AI - efficient AI deployment - static AI applications - semantic search - knowledge graphs Create: - title options - meta description - suggested URL slug - suggested tags - suggested internal links to related articles on danielkliewer.com Include suggestions for: - diagrams that should be created - code snippets worth showing - screenshots from the repository - a visual explanation of the architecture Finally, produce the complete publish-ready article in Markdown format suitable for my Next.js MDX blog. ``` I would also have the model **read your existing posts first** before writing. The biggest advantage you have is not just the idea; it is the narrative continuity between your projects (Dynamic Persona MoE RAG → autonomous architectures → sovereign AI → Knowledge Compiler). A good article should make readers feel like this is the next logical evolution of your research rather than an isolated experiment. One additional suggestion: have the LLM generate **two versions**: 1. A research-focused version aimed at AI engineers. 2. A business-facing version aimed at consulting clients. The same project can attract both audiences, but they respond to different framing.