Telemetry in Web Development

so I think I fixed all the issues on my site but I wont' know for two days up to possibly but I hope the analytics work now because I am flying blind without telemetry, explain better how telemetry can be used in an application such as some of my recent explorations into telemetry

Given the way you have been rebuilding `danielkliewer.com`, telemetry is actually one of the missing pieces that makes the difference between **building a system** and **guessing about a system**. You have been doing a lot of work around knowledge graphs, RAG, agents, UX, SEO, and content architecture — but without telemetry you are effectively operating the way an ML model operates without a loss function: you can generate outputs, but you don't have feedback about whether the outputs are moving toward the objective. Your recent exploration into telemetry (GA4, Tag Assistant, debugging tracking, thinking about observability) is actually very aligned with the larger themes you have been developing. ## Telemetry is the nervous system of an application A useful analogy: - **Application code** = the body - **Users** = the environment - **Telemetry** = the nervous system - **Analytics dashboards** = the brain interpreting signals - **Optimization loops** = learning Without telemetry, the application cannot "feel." A website can be beautiful, technically impressive, and full of content, but you don't know: - Which pages actually matter - Where people enter - Where they leave - Which ideas resonate - Which components are confusing - Which errors are happening silently - Whether your SEO strategy works - Whether your AI experiments create engagement You are essentially running an experiment without collecting observations. --- # The telemetry stack Most people think telemetry means "Google Analytics page views." That is only one layer. A modern application usually has several layers: ## 1. Product analytics (behavior telemetry) This answers: > "What are humans doing?" Examples: ``` User visits /projects | v Scrolls 75% | v Clicks Dynamic Persona RAG project | v Reads article for 6 minutes | v Downloads GitHub repo ``` Events might look like: ```json { "event": "project_view", "project": "dynamic_persona_moe_rag", "source": "google", "session_id": "abc123" } ``` Over time you discover: - "People who read my AI architecture posts also visit my portfolio" - "Nobody clicks my old projects" - "People spend 8 minutes on my RAG posts" - "My homepage is not converting" That changes your decisions. --- # 2. Performance telemetry This answers: > "Is the machine healthy?" Examples: ``` Page load: 0.8s JS bundle: 400kb Largest Contentful Paint: 1.2s API response: 120ms ``` For your site, this matters because you have: - Next.js - Framer Motion - animations - MDX rendering - possible graph visualization - client-side components A beautiful site can accidentally become slow. Telemetry catches: ``` Homepage: 95% successful Projects page: Mobile: 30% abandoned JS error spike ``` Which is exactly the kind of thing you were seeing with the Evolution section. --- # 3. Error telemetry This is probably the most important one for you right now. Users rarely report errors. They simply disappear. Example: Your mobile Evolution section: ``` User opens page React hydration mismatch Component fails Browser silently removes section User leaves You never know ``` Error telemetry would tell you: ``` Error: Hydration failed because server HTML differs Occurrences: 1,842 Devices: iPhone Safari 82% First seen: July 7 ``` Tools like Sentry are designed around this idea. --- # 4. AI telemetry (where this connects to your recent work) This is where your explorations become interesting. An AI system without telemetry is extremely difficult to improve. For a RAG system, you need to observe: ``` User question | v Retriever | v Documents selected | v Prompt constructed | v LLM response | v User feedback ``` Telemetry might record: ```json { "query": "How does Dynamic Persona MoE work?", "retrieved_docs": [ "autonomous_architectures.md", "dynamic_persona.md" ], "similarity_scores": [ 0.91, 0.86 ], "response_length": 800, "feedback": "positive" } ``` Then you can ask: - Are the right documents retrieved? - Are embeddings working? - Are personas improving output? - Are users asking questions you cannot answer? This is exactly the missing feedback loop in many AI projects. --- # Your "knowledge graph + telemetry" idea is actually powerful You have been thinking about your blog as a knowledge graph. Imagine combining: ## Static graph Your content: ``` RAG | +-- embeddings | +-- knowledge graphs | +-- agents | +-- personas ``` with: ## Dynamic graph Your audience behavior: ``` Visitor A | reads | Dynamic Persona article | clicks | GitHub repo | downloads ``` Now your website becomes self-observing. The graph changes based on: - what you write - what people consume - what questions they ask - what paths they take This is close to the idea behind a **digital twin** of a system. --- # Your current situation: "flying blind" That phrase is actually accurate. Right now you have been doing a lot of: ``` Generate -> Build -> Deploy ``` but missing: ``` Measure -> Analyze -> Improve ``` The complete loop is: ``` +-------------+ | | v | Build ---> Deploy ---> Observe | ^ | | | +--- Improve - ``` Telemetry closes the loop. --- # For danielkliewer.com specifically, I would eventually want: ## Visitor telemetry - page views - reading time - scroll depth - outbound GitHub clicks - newsletter/contact clicks ## Content telemetry For each post: ``` title topic views avg reading time referral source related articles clicked ``` ## Technical telemetry - Core Web Vitals - JS errors - failed builds - API failures ## AI telemetry (future) If you add your knowledge graph assistant: ``` Question asked Documents retrieved Answer generated User satisfaction Missing knowledge detected ``` Then the AI system can literally tell you: > "Visitors frequently ask about GraphRAG, but your knowledge base has only three weak documents on this topic." That becomes an automated content strategy engine. --- The interesting thing about your recent work is that you have been moving from "creating content" toward "creating a self-improving information system." Telemetry is the piece that turns that from a static website into an adaptive system. Your GA4 fix matters because it is the first feedback sensor. Once you know the sensors work, the next step is not necessarily adding more features — it is building better feedback loops around the features you already have.

exactly I can probably export the analytics directly and be able to utilize it and use it to construct graphs of its own using local inference, so what if we used RAG on a .json or whatever of the graph built from local llm parsing of content into the graph database allowing the ability to chat with your analytics and be able to derieve heurtistics and have those recommended that you would not normally see

Yes — this is actually a very natural extension of the architecture you have been exploring. What you are describing is essentially **Telemetry-Augmented GraphRAG**: using analytics data as a continuously evolving knowledge source, constructing a behavioral graph, and then using local inference to reason over patterns that ordinary dashboards do not expose. The key insight is that analytics data is not just a collection of numbers. It is a record of **interactions between entities**. Traditional analytics says: > "Page X had 1,200 views." A graph-oriented analytics system asks: > "What relationship exists between visitors, ideas, pages, acquisition channels, and outcomes?" Those are very different questions. --- ## The pipeline could look something like this ``` GA4 Export | v Raw Events JSON | v Local LLM Extraction | v Behavioral Knowledge Graph | v Graph + Vector Retrieval | v Local LLM Analyst | v Insights / Recommendations ``` --- ## 1. Start with raw telemetry GA4 exports are essentially event streams: ```json { "event_name": "page_view", "timestamp": "2026-07-09T20:00:00", "page": "/projects/dynamic-persona-rag", "country": "US", "device": "mobile", "source": "google" } ``` But raw telemetry is not very useful. The interesting part is extracting meaning. --- ## 2. Convert events into entities and relationships A local model could transform this into graph objects. For example: ### Entities ``` Page ├── Dynamic Persona RAG ├── Autonomous Architectures ├── About Topic ├── RAG ├── AI Agents ├── Knowledge Graphs Visitor Segment ├── Search Visitor ├── Returning Reader ├── Developer Audience ``` ### Relationships ``` Visitor Segment | reads | v Dynamic Persona RAG | relates_to | v Knowledge Graphs ``` Now you have something queryable. --- ## 3. Add semantic understanding with local inference This is where your local models become interesting. Instead of only storing: ``` Page: dynamic_persona_rag.md Views: 800 ``` the LLM can annotate: ```json { "page": "dynamic_persona_rag", "concepts": [ "agent architecture", "persona modeling", "retrieval systems" ], "audience": [ "AI engineers", "researchers" ], "intent": "technical credibility" } ``` Now your analytics graph understands *meaning*. --- ## 4. RAG over the analytics graph Then you can ask questions like: > "What content attracts people interested in local AI?" The system could traverse: ``` Local AI | | Visitors | | Read: Ollama article Local inference article RAG article | | Common next action: GitHub click ``` The answer might be: > "Visitors interested in local inference are 3.2x more likely to read your Dynamic Persona RAG article after reading the Ollama post. Consider adding a direct navigation path between those pages." A normal GA dashboard would probably never reveal that. --- ## 5. Heuristic generation The really interesting part is your idea of recommendations that you "would not normally see." The system could generate hypotheses. Example: ``` Observation: People arriving from Google search: "local LLM MacBook" Behavior: - Read Ollama post - Read hardware post - Leave Inference: They have high technical curiosity but lack a conversion path. Recommendation: Create: "Running Local AI on Apple Silicon: Complete Guide" Link: Ollama → Hardware → Your RAG project ``` That is essentially an AI growth analyst. --- ## 6. You could even create multiple analytical personas This connects directly to your Dynamic Persona MoE idea. Instead of one analyst: ``` Analytics Assistant ``` you could have: ``` SEO Analyst Persona | analyzes search traffic Product Manager Persona | analyzes conversions Researcher Persona | analyzes knowledge gaps UX Persona | analyzes user journeys ``` Each one has different heuristics. The SEO persona might say: > "Your article has high impressions but low CTR." The researcher persona might say: > "Your graph shows a missing connection between AI agents and knowledge graphs." The product persona might say: > "People who read your technical posts do not find your services page." --- ## 7. The important architectural decision I would **not** put everything directly into the vector database. You probably want: ``` Analytics JSON | | Event Processor | +--------------+--------------+ | | v v Knowledge Graph Vector Database (nodes/edges) (semantic chunks) \ / \ / +-----------+-------------+ | v Local RAG Agent ``` The graph handles: - relationships - sequences - causality hypotheses The vector database handles: - semantic similarity - fuzzy retrieval - documents They complement each other. --- The really interesting meta-layer is that your own website could become a laboratory for the architecture you have been theorizing about. You would have: 1. **Content graph** — what ideas exist 2. **Behavior graph** — what humans interact with 3. **Knowledge graph** — how concepts relate 4. **Inference layer** — what the system believes is happening 5. **Action layer** — what changes it recommends At that point, your website is no longer just a portfolio. It becomes a self-observing information system. The first practical MVP would actually be fairly small: export GA4 events → normalize into JSON → create a NetworkX graph → embed summaries into ChromaDB → ask your local model questions about your own audience. That would validate the entire concept before adding Neo4j or more complex orchestration.

create a spec for this

Below is a technical specification for building the first version of the system. I would treat this as an extension of your existing **Dynamic Persona MoE RAG / knowledge graph architecture**, but focused specifically on **analytics intelligence**. # Telemetry Intelligence GraphRAG System Specification ## Project Name **Telemetry Intelligence Engine (TIE)** A local-first analytics reasoning system that transforms website telemetry into a behavioral knowledge graph, enriches it using local LLM inference, and provides RAG-based analytical capabilities for discovering non-obvious patterns, heuristics, and optimization opportunities. --- # 1. Objective Build a system that allows an operator to ask questions about their website's behavior using natural language: Examples: > "What topics are attracting the highest-value visitors?" > "What content pathways lead people toward my projects?" > "What concepts are underrepresented compared to visitor interest?" > "What should I write next based on observed knowledge gaps?" > "Why are visitors leaving after reading certain pages?" The system should combine: - Google Analytics telemetry - Content metadata - Knowledge graph relationships - Local LLM reasoning - Vector retrieval - Automated recommendation generation --- # 2. Core Architecture ``` +----------------+ | GA4 Export | +--------+-------+ | v Raw Telemetry JSON | v +---------------------+ | Telemetry Processor | +---------------------+ / \ / \ v v Behavioral Graph Vector Database (NetworkX/Neo4j) (ChromaDB) \ / \ / v v +--------------------+ | Local RAG Analyst | | Ollama / llama.cpp | +--------------------+ | v Insights + Recommendations ``` --- # 3. Data Sources ## 3.1 Analytics Data Initial source: Google Analytics 4 export. Required fields: ```json { "timestamp": "", "event_name": "", "page_path": "", "session_id": "", "user_country": "", "device_category": "", "traffic_source": "", "referrer": "", "engagement_time": "", "scroll_depth": "", "events": [] } ``` Future integrations: - Search Console - GitHub analytics - Newsletter metrics - Social referrals - Server logs - Error telemetry --- # 4. Content Knowledge Layer The system should ingest existing website content. Sources: ``` /content | +-- blog/ +-- projects/ +-- essays/ ``` Each document becomes a graph entity. Example: ```json { "id": "dynamic_persona_rag", "type": "article", "title": "Dynamic Persona MoE RAG", "topics": [ "RAG", "agents", "knowledge graphs" ], "entities": [ "Ollama", "ChromaDB", "LLMs" ] } ``` --- # 5. Knowledge Graph Schema ## Nodes ### Content Nodes ``` Article Project Page Repository Topic Keyword Technology ``` --- ### User Behavior Nodes ``` Visitor Segment Session Traffic Source Device Type Conversion Event ``` --- ### Analytical Nodes ``` Hypothesis Recommendation Opportunity Knowledge Gap Trend ``` --- # 6. Graph Relationships Examples: ``` Visitor | viewed | v Article Article | discusses | v Topic Topic | related_to | v Project Article | leads_to | v Conversion ``` Behavior paths: ``` Google Search | v Ollama Article | v Dynamic Persona RAG | v GitHub Click ``` --- # 7. LLM Enrichment Pipeline ## Purpose Convert raw telemetry into semantic intelligence. --- ## Stage 1: Event Summarization Input: ```json { "page":"/projects/rag", "views":1200, "time":240 } ``` Output: ```json { "meaning": "High-interest technical content attracting AI engineering audience" } ``` --- ## Stage 2: Entity Extraction Local model extracts: ``` Topics: - AI Agents - Retrieval Systems - Local Inference Audience: - Developers - Researchers Intent: - Technical exploration ``` --- ## Stage 3: Relationship Discovery Model proposes: ``` Dynamic Persona RAG related_to Knowledge Graphs because: Both discuss structured information retrieval ``` Human approval optional. --- # 8. Vector Database Layer Use: - ChromaDB initially - Optional migration to Qdrant later Collections: ``` analytics_events content_embeddings graph_summaries recommendations ``` Example embedding: ``` "The visitor journey from local AI article to RAG project" ``` --- # 9. RAG Query System The user asks: ``` "What are my biggest content opportunities?" ``` Retrieval process: ``` Question | v Semantic Retrieval | v Relevant Graph Neighborhood | v LLM Reasoning | v Answer ``` --- # 10. Analytical Personas Implement using your existing persona architecture. ## SEO Analyst Focus: - impressions - rankings - search intent - missing content Output: ``` Create article: "Running Local AI on Apple Silicon" ``` --- ## Product Analyst Focus: - conversions - funnels - user intent Output: ``` Add stronger CTA after technical articles. ``` --- ## Research Analyst Focus: - conceptual relationships Output: ``` Knowledge gap: AI agents ↔ knowledge graphs ``` --- ## UX Analyst Focus: - user journeys Output: ``` Mobile visitors abandon project pages. Investigate animation performance. ``` --- # 11. Recommendation Engine The system generates: ## Observations Facts: ``` Dynamic Persona RAG: 400 visitors 8 minute average reading time ``` --- ## Hypotheses Reasoned conclusions: ``` Technical architecture content attracts highly engaged visitors. ``` --- ## Actions Recommendations: ``` Create navigation path: RAG Article → Project Demo → GitHub ``` --- # 12. Automated Reports Generate weekly: ``` Telemetry Intelligence Report 1. New Trends 2. Visitor Behavior Changes 3. Content Opportunities 4. Technical Problems 5. Recommended Experiments ``` Stored as: ``` /reports | +-- 2026-07-09-analysis.md ``` These reports themselves become RAG documents. --- # 13. Technology Stack ## Existing Frontend: - Next.js - TypeScript - Tailwind Backend: - Python - FastAPI AI: - Ollama - llama.cpp - Qwen models Storage: - SQLite - ChromaDB - NetworkX --- ## Future Graph database: - Neo4j Observability: - OpenTelemetry Analytics: - PostHog --- # 14. MVP Implementation Plan ## Phase 1 — Telemetry Ingestion Goal: Get data flowing. Tasks: - Export GA4 data - Normalize JSON - Store locally - Create schema --- ## Phase 2 — Graph Construction Tasks: - Create nodes - Create relationships - Visualize graph Output: ``` website_behavior_graph.html ``` --- ## Phase 3 — RAG Layer Tasks: - Embed graph summaries - Add ChromaDB - Connect local model --- ## Phase 4 — Analyst Agent Create: ``` TelemetryAgent ``` Capabilities: - Query analytics - Explain trends - Generate recommendations --- ## Phase 5 — Self-Improving Loop Add: ``` Recommendation | v Implement change | v Measure outcome | v Update confidence ``` --- # 15. Success Criteria The system succeeds when it can answer questions that standard analytics cannot: Example: > "Visitors interested in local AI are not finding my business offerings. They are reading technical posts but never reaching the services page. Create a bridge article connecting these concepts." At that point, telemetry is no longer just reporting the past. It becomes a **reasoning layer for improving the system itself**.

I finally fixed the bug and got analytics to work, kind of. I spent all day trying to get the Google Analytics to work which is the telemetry you get from user interaction with your site. I had a plan to afterwards export the data of user interactions and generate a graph to be optimized allowing inferences to be created from the data. It would be perfect for marketing intelligence. It basically takes my idea about agentic knowledge graphs and applies them to the analytics data created from user interaction with the site. I had been using Vercel’s Analytics which are much easier to set up. They also pale in comparison to what you can do and observe. Which is why I wanted to switch to Google’s version. I tried all day. I removed other functionality and added it back and did this and that and everything you can think of to make it work. The problem is that I can’t get it set up with just a bot. Google makes it so that you need a human to set up a lot of their services, and this one requires you to navigate a byzantine path of set up pages all with options you have to iteratively turn off or on in order to try every permutation until you get it to work. The other thing was that the final step says that it could take 48 hours to see it complete. So each time you change something does that reset the 48 hours? We will never know. Then there was the mobile issue. Well, somehow it fixed itself, probably when I removed or reset one of the other services trying to get the analytics to work. After all day had transpired and the mobile issue corrected itself somehow I finally have given up on Google Analytics and have gone back to Vercel. It was dead simple to get to work and so now I have telemetry again. Except now I have a few days gap in the telemetry due to removing Vercel’s analytics and attempting the last few days to get Google’s to work. If I am going to take my blogging game further I will need to get the Google Analytics to work. But that will have to be some day in the future. It is basically like this, Vercel’s analytics are to Algebra what Google’s are to Calculus in terms of the complexity and possibilities it allows. At least with my current understanding so I may have to continue to investigate this to see if I can achieve the same level of detail using Vercel. I don’t see why not since Vercel is the preeminent frontend technology right now.

Your post already has a good narrative arc, but it can be tightened and made more reflective while connecting it back to the larger idea you're exploring. Here's a polished version: :::writing{variant="document" id="41287"} Today was supposed to be the day I began experimenting with a new idea: using website telemetry as another knowledge source for agentic knowledge graphs. The idea is simple in principle. Every interaction a visitor has with a website—page views, navigation paths, reading time, scroll depth, referrals—is telemetry. Instead of treating that telemetry as charts on a dashboard, I want to export it, transform it into a graph of relationships, and use local LLMs to reason over it. In other words, apply the same GraphRAG and agentic knowledge graph concepts I've been exploring to the behavioral data generated by the website itself. Rather than asking, "How many people visited this page?", I want to ask questions like: - Which ideas consistently lead readers toward my projects? - What concepts are visitors interested in that I haven't written enough about? - What paths do engaged readers follow through the site? - What content should I create next based on observed knowledge gaps? - What recommendations would an AI analyst derive that aren't immediately obvious from conventional dashboards? Instead of analytics being something you look at, analytics becomes something you can have a conversation with. Unfortunately, none of that happened today. Instead, I spent the entire day trying to get Google Analytics working. I had been using Vercel Analytics, which is almost effortless to configure. Google Analytics, on the other hand, offers dramatically more flexibility—but getting there feels like navigating a maze. Every screen presents another collection of checkboxes, permissions, integrations, and configuration options, many of which seem to interact in opaque ways. You make one change, test it, wait, make another change, test again, and gradually lose confidence that you're even making progress. To make matters worse, the final setup step warns that data may take up to 48 hours to appear. That creates an almost impossible debugging experience. If every configuration change potentially resets the waiting period, how do you know whether you actually fixed the problem or simply haven't waited long enough? It becomes difficult to distinguish between a broken configuration and eventual consistency. While wrestling with analytics, I was also trying to solve a separate mobile rendering issue on my Projects page. At some point, that bug simply disappeared. I still don't know exactly why. My best guess is that removing and re-enabling various scripts or services changed the conditions that were triggering it. It's always a little unsettling when a bug fixes itself before you've identified the root cause. By the end of the day I gave up, re-enabled Vercel Analytics, and within minutes telemetry was flowing again. That at least gives me visibility into what's happening on the site, although I now have a gap of several days in my analytics from removing Vercel while experimenting with Google's implementation. Eventually I still want Google Analytics working. The way I currently think about the difference is that Vercel Analytics is like algebra, while Google Analytics is like calculus. Algebra solves many practical problems with far less complexity. Calculus opens the door to much more sophisticated reasoning, but only after investing significantly more effort into understanding the machinery. Whether that analogy ultimately holds remains to be seen. Vercel is built by one of the leading frontend platforms, so it may already expose enough information to support many of the ideas I have in mind. I haven't explored its capabilities deeply enough to know where its limits actually are. What I'm ultimately interested in isn't analytics for the sake of analytics. I'm interested in building a self-observing information system. Imagine combining a knowledge graph of the content itself with a behavioral graph built from visitor interactions. One graph represents ideas; the other represents how people navigate those ideas. Feed both into a local inference system, and suddenly the website becomes capable of reasoning about its own evolution. Instead of simply reporting that an article received 1,200 views, the system might infer that readers interested in local AI consistently progress to knowledge graph content but rarely discover related projects. It could recommend new articles, better internal links, or identify conceptual gaps in the site's coverage. Rather than generating dashboards, it would generate hypotheses. That's the direction I want to explore next. Today I didn't get there. Today was about building the sensors. ::: I like that this version ends on "Today was about building the sensors." It reframes what felt like a frustrating day into the first step of a longer project: before a system can reason about itself, it first has to be able to observe itself.

Today was supposed to be the day I began experimenting with a new idea: using website telemetry as another knowledge source for agentic knowledge graphs. The idea is simple in principle. Every interaction a visitor has with a website—page views, navigation paths, reading time, scroll depth, referrals—is telemetry. Instead of treating that telemetry as charts on a dashboard, I want to export it, transform it into a graph of relationships, and use local LLMs to reason over it. In other words, apply the same GraphRAG and agentic knowledge graph concepts I’ve been exploring to the behavioral data generated by the website itself. Rather than asking, “How many people visited this page?”, I want to ask questions like: Which ideas consistently lead readers toward my projects? What concepts are visitors interested in that I haven’t written enough about? What paths do engaged readers follow through the site? What content should I create next based on observed knowledge gaps? What recommendations would an AI analyst derive that aren’t immediately obvious from conventional dashboards? Instead of analytics being something you look at, analytics becomes something you can have a conversation with. Unfortunately, none of that happened today. Instead, I spent the entire day trying to get Google Analytics working. I had been using Vercel Analytics, which is almost effortless to configure. Google Analytics, on the other hand, offers dramatically more flexibility—but getting there feels like navigating a maze. Every screen presents another collection of checkboxes, permissions, integrations, and configuration options, many of which seem to interact in opaque ways. You make one change, test it, wait, make another change, test again, and gradually lose confidence that you’re even making progress. To make matters worse, the final setup step warns that data may take up to 48 hours to appear. That creates an almost impossible debugging experience. If every configuration change potentially resets the waiting period, how do you know whether you actually fixed the problem or simply haven’t waited long enough? It becomes difficult to distinguish between a broken configuration and eventual consistency. While wrestling with analytics, I was also trying to solve a separate mobile rendering issue on my Projects page. At some point, that bug simply disappeared. I still don’t know exactly why. My best guess is that removing and re-enabling various scripts or services changed the conditions that were triggering it. It’s always a little unsettling when a bug fixes itself before you’ve identified the root cause. By the end of the day I gave up, re-enabled Vercel Analytics, and within minutes telemetry was flowing again. That at least gives me visibility into what’s happening on the site, although I now have a gap of several days in my analytics from removing Vercel while experimenting with Google’s implementation. Eventually I still want Google Analytics working. The way I currently think about the difference is that Vercel Analytics is like algebra, while Google Analytics is like calculus. Algebra solves many practical problems with far less complexity. Calculus opens the door to much more sophisticated reasoning, but only after investing significantly more effort into understanding the machinery. Whether that analogy ultimately holds remains to be seen. Vercel is built by one of the leading frontend platforms, so it may already expose enough information to support many of the ideas I have in mind. I haven’t explored its capabilities deeply enough to know where its limits actually are. What I’m ultimately interested in isn’t analytics for the sake of analytics. I’m interested in building a self-observing information system. Imagine combining a knowledge graph of the content itself with a behavioral graph built from visitor interactions. One graph represents ideas; the other represents how people navigate those ideas. Feed both into a local inference system, and suddenly the website becomes capable of reasoning about its own evolution. Instead of simply reporting that an article received 1,200 views, the system might infer that readers interested in local AI consistently progress to knowledge graph content but rarely discover related projects. It could recommend new articles, better internal links, or identify conceptual gaps in the site’s coverage. Rather than generating dashboards, it would generate hypotheses. That’s the direction I want to explore next. Today I didn’t get there. I have learned a lot more about what capabilities there are for telemetry and how the industry works. Although most of my experience is with Google Cloud; Amazon Web Services and Microsoft’s Azure all have the same inherent functionality and it would not be too difficult to use. This analytics headache isn’t even that complex in terms of what Google Cloud has to offer. But most of that functionality I have no experience with requires you to pay money to use. That is why DevOps engineers with over 8 years of experience deploying enterprise systems are so rare and valuable. Because in order to have experience using the software services you have to have the budget of an enterprise to pay for the usage. So either you are working for a large company or you have your own business you have scaled with a project allowing you to get the experience on your own. What enterprise systems allow is amazing. Imagine it this way. I can build an application to use on my laptop but it will run slowly and take forever to use because of the limits of my laptop’s hardware. But if I were using hyperscalers and deployed the application on Google Cloud, then you can increase the compute used according to the need and if you have enough money to pay for compute it doesn’t matter how slowly it runs locally because with hyperscalers it will run lighting fast for everyone who uses it. This is why data centers are being built. It is because they want to run software requiring more compute than what local devices have to offer through using hyperscalers. The philosophy behind everything I have built is centered around local development. If I build something and it runs too slowly on my computer then I work harder until it is more efficient and uses less compute. Why? Because if I wanted to speed it up using hyperscalers I would have to pay for it for each usage. That adds up very quickly. It also means I would need to send all my data to the cloud and rely on Google doing everything they are supposed to do and not be beholden to do whatever the US Government imposes on them. So while I do not have experience using hyperscalers, that actually has made my software more valuable. Because if it does not run locally I have to work and make it more efficient until it uses low enough compute to be runnable. Thus, if it ever is scaled up, the compute it uses is far lower than if you just had an unlimited budget for hyperscalers. The way to get experience with scaled projects is a MVP or minimal viable product. Which to me means that the price you pay for compute is lower than the revenue brought in by the product. So that also means that there can exist many “not-minimally viable products” just like there can be business models which do not bring in more revenue than they spend. What my philosophy is is that you should build software which runs on local edge devices and requires no hyperscalers whatsoever, or at least as little as possible. This means that it runs for free forever. While if you create software which requires more compute than local devices are capable of, then you are either losing money running it or you have a successful enough business model to bring in revenue. While these hyperscalers allow you to run much more powerful programs, what I argue is that you do not need that. What we have now is this idea that if you require more compute than what edge devices are capable of because your software requires more compute to run than what is available to edge devices then you have to rely on the internet connected stream of your application from the cloud to be streamed to edge devices. That is not free. It requires a lot of infrastructure and most notably data centers. What my argument is is this. We have reached the critical threshold where you have a powerful enough edge device to host a local agentic system capable of modifying the software infinitely. At this point much of the functionality we get from cloud services can now be provided by the inference that is local. So it is like this. Edge devices before if they wanted advanced functionality would require on hyper scaled apps in the cloud. Now with local inference capable of building new tools as needed you can get an equivalent to the cloud app’s functionality created at will. Why would you pay for a piece of software when you can just tell your coding agent to add the functionality itself? Walstreet wants this, for software to become so advanced that it requires more compute than what edge devices are capable of. So to run the software it requires scaled software using data centers. This creates an economy of users paying for the scaled software which could not run on their local devices. The greater the demand and usage of the software, the greater the profits. So it is something which can scale up further and further as you invest more and more money into. But what happens when you reach the threshold I have described? If, I posit, that much of the functionality people are paying for, that is API access to coding agents paying per token, is available with local edge devices then that device does not need the cloud and instead of paying an external provider per usage they can run simply for the cost of electricity to run their local device. So the idea that data centers are essential is bogus. At least long term. As more and more devices become capable of running this critical threshold I have achieved on my own device, then the need for paying for subscription or per usage software drops significantly. What happens when your local inference can do everything and all of your software runs fast enough without need for hyperscalers? This is why the entire concept of hyperscalers for software is cancerous. It is like spending more than you earn. It is not sustainable without wealth extraction. That is the difference between my local philosophy for software development versus what silicon Vally is selling us with their attempt to create software requiring more and more compute for no good reason. If we can deliver the value of the software all done locally then the infrastructure becomes more efficient. It means fewer profits for software developers but it would benefit EVERY other sector of the economy.

This has grown into two distinct essays that are competing with each other. The first half is about **telemetry and self-observing systems**. The second half is about **local-first computing versus hyperscalers**. Both are interesting, but by combining them you've diluted the impact of each. The transition happens here: > "Today I didn't get there." That is actually an excellent ending for the telemetry essay. Everything after that changes subjects. The second essay deserves to stand on its own because it raises a much larger thesis. There are a few places where I'd also refine the argument. First, I'd avoid absolute statements like: > "The idea that data centers are essential is bogus." That's stronger than your argument actually needs to be, and it invites easy counterexamples. There are workloads—training frontier models, global search indexes, large-scale video streaming, scientific simulations—that genuinely benefit from or require large centralized infrastructure. I think your actual argument is more nuanced and stronger: > "A growing class of software that previously required cloud infrastructure can now execute entirely on increasingly capable edge devices, shifting the economic tradeoff toward local-first architectures." That is a claim you can defend. Likewise, I'd avoid calling hyperscalers "cancerous." That metaphor distracts from the technical point. You're making an architectural and economic argument, not a moral one. I think what you're really describing is something like this: > Centralized compute should be reserved for problems that actually require centralized compute. That's a compelling principle. Your observation about incentives is also worth developing. Cloud providers naturally have incentives that differ from someone building local software: - Cloud providers benefit when applications consume more compute. - Developers paying cloud bills benefit when applications become more efficient. - Users benefit when software is cheaper, faster, more private, and continues working offline. Those incentives are not always aligned, and that's an interesting discussion. I also like this sentence: > "If I build something and it runs too slowly on my computer then I work harder until it is more efficient and uses less compute." That feels like the core of your philosophy. You could even elevate it into a design principle: > **Local-first software forces computational discipline. Every unnecessary computation has a direct cost to the developer.** That connects nicely with another idea you've been exploring: convergence rather than endless expansion. One thing I found particularly interesting is that your telemetry project itself demonstrates this philosophy. Instead of buying another SaaS analytics platform or relying on hosted AI services, you're proposing to: - export telemetry, - build a local behavioral graph, - run GraphRAG locally, - generate recommendations locally. The architecture embodies the philosophy. If I were organizing these into blog posts, I'd split them into two: 1. **Building a Self-Observing Website** — everything through "Today I didn't get there." This is about telemetry, analytics, GraphRAG, and AI reasoning over user behavior. 2. **The Local-First Threshold** (or **The Edge Compute Threshold**) — the rest of the essay. This is about a broader shift in software architecture: as edge devices become capable of local inference, the set of applications that genuinely require hyperscalers shrinks. Cloud remains valuable for global coordination, elastic scaling, and compute-intensive workloads, but many applications that once depended on it may no longer need to. I think the second essay contains one of your more original ideas. It's not simply "local is better." It's the observation that **local inference changes the economic boundary between what must be centralized and what can be decentralized**. That's a much sharper thesis, and it deserves to be developed without being overshadowed by the story of debugging analytics.

write the edge compute threshold blog post

I'd frame it as an essay about a changing architectural boundary rather than as a prediction that the cloud will disappear. That makes the argument stronger and more technically grounded. :::writing{variant="document" id="58341"} # The Edge Compute Threshold For most of the history of personal computing, there has been a simple rule. If an application became too computationally expensive to run on a user's device, it moved to the cloud. The cloud wasn't simply more convenient—it was necessary. Running sophisticated software required hardware that individual users didn't possess. Companies built massive data centers, exposed their compute through APIs, and charged customers based on usage. That model made perfect sense. Today, I think we are approaching an architectural threshold where the assumptions behind that model begin to change. I call it the **Edge Compute Threshold**. ## The Local Constraint Nearly everything I build begins on my own computer. I don't start by asking how many GPUs I can rent or how many API calls I can afford. Instead, I ask a different question: **Can I make this run locally?** That constraint changes how software is designed. If an application runs slowly on my machine, I don't immediately solve the problem by adding more hardware. I profile it. I optimize algorithms. I reduce memory usage. I cache intelligently. I rethink the architecture until it becomes efficient enough to run well on commodity hardware. The result isn't simply cheaper software. It is often better software. Efficiency stops being an afterthought and becomes a design philosophy. ## Hyperscalers Changed Everything Cloud platforms such as Google Cloud, Microsoft Azure, and Amazon Web Services fundamentally changed software development. Instead of being constrained by local hardware, developers could provision nearly unlimited compute on demand. Need more CPUs? Allocate them. Need more storage? Provision it. Need another GPU cluster? Spin one up. Entire industries have been built on this ability to scale computational resources almost without limit. That capability remains extraordinary. Many workloads genuinely require it. Large-scale search indexes, distributed databases, scientific simulations, global multiplayer services, and frontier AI model training all benefit enormously from centralized infrastructure. The cloud solved real problems. ## But AI Is Moving the Boundary What has changed is not that cloud computing has become less useful. What has changed is the capability of edge devices. Modern laptops can run language models that, only a few years ago, required enterprise hardware. Phones now contain neural processing units dedicated to local inference. Consumer desktops routinely ship with GPUs capable of running sophisticated AI workflows. The important development isn't simply that devices are becoming faster. It is that local inference fundamentally changes what software can do without contacting a remote server. Previously, advanced functionality almost always implied cloud computation. Now many forms of intelligence can exist entirely on the device. That is a significant architectural shift. ## Software That Builds Itself One consequence of local inference is something I find even more interesting. Software no longer needs to contain every feature in advance. Instead, a local coding agent can generate new functionality as needed. Need a parser? Generate it. Need a visualization? Build it. Need a workflow? Compose it. The software becomes less like a static application and more like a continuously evolving system. Historically, adding functionality often meant subscribing to another SaaS product or integrating another API. Increasingly, it may simply mean asking your local agent to write the code. ## The Economics Change Cloud infrastructure is remarkably powerful, but it also changes the economics of software. Every request has a cost. Every inference consumes resources. Every user increases operating expenses. Those costs are entirely reasonable when they create proportional value. But if the same computation can happen locally, the equation changes. Running software on an edge device generally requires only the hardware already owned by the user and the electricity needed to operate it. Instead of paying continuously for remote computation, the cost becomes largely fixed. For some classes of applications, that is a profound difference. ## The Edge Compute Threshold The threshold I am describing is the point at which an edge device becomes capable enough that local inference can replace a meaningful portion of what previously required cloud services. This doesn't eliminate the cloud. Instead, it changes what belongs there. Cloud infrastructure remains invaluable for: - Global synchronization - Large-scale collaboration - Massive datasets - Elastic compute - High-availability services - Training frontier models But many individual productivity applications, knowledge systems, coding assistants, and personal AI workflows no longer require continuous cloud dependence. The cloud becomes optional rather than mandatory. ## Designing Under Constraint Ironically, building locally may produce software that scales better. When developers assume effectively unlimited compute, inefficient architectures often survive because additional hardware masks their weaknesses. When developers target edge devices first, inefficiencies become impossible to ignore. Every unnecessary computation must justify itself. Every optimization has immediate value. Software becomes computationally disciplined. If that software is eventually deployed to cloud infrastructure, it typically consumes fewer resources than an equivalent system designed without those constraints. Local-first development therefore creates benefits even when software ultimately scales beyond a single machine. ## A Different Philosophy My interest has never been in rejecting cloud computing. It is in asking whether we actually need it for a given problem. For decades, software architecture assumed that increasingly sophisticated applications would inevitably become centralized. Local AI challenges that assumption. Perhaps the future is not one giant model serving billions of users from a handful of data centers. Perhaps it is millions of increasingly capable edge devices performing inference locally, collaborating only when necessary. That is a very different vision of computing. ## Looking Forward I suspect we are entering a period where software architecture will increasingly be defined by a single question: **Does this computation actually need to leave the device?** As local hardware continues to improve and open-source models become more capable, the answer to that question will increasingly be "no." When that happens, software becomes cheaper to operate, more private, more resilient to connectivity issues, and less dependent on centralized infrastructure. Cloud computing will not disappear. But its role will change. The most successful systems may not be those that consume the most compute, but those that intelligently divide work between the edge and the cloud, using each where it provides the greatest advantage. Crossing the Edge Compute Threshold does not mean abandoning the cloud. It means recognizing that intelligence has finally become portable. ::: I think this version presents the idea as an architectural thesis rather than a manifesto. That makes it easier for readers—especially engineers—to engage with the argument on its technical merits, even if they disagree about how quickly the shift will happen.

now make a linkedin post based on it

Here's a version tailored for LinkedIn that focuses on the core idea and invites discussion rather than trying to make the entire argument. :::writing{variant="social_post" id="68412"} I think we're approaching an architectural inflection point in software development. For decades, the rule was simple: when an application became too computationally expensive to run locally, you moved it to the cloud. That assumption made perfect sense. But local AI is changing where that boundary lies. Modern laptops and even phones are now capable of running language models and agentic workflows that, only a few years ago, required enterprise infrastructure. As edge devices become more capable, an increasing number of applications no longer *need* continuous cloud inference. I've started thinking about this as the **Edge Compute Threshold**. It's the point where a device becomes capable enough that local inference can replace a meaningful portion of what previously required hyperscalers. This doesn't make cloud computing obsolete. There will always be workloads where centralized infrastructure is the right solution: • Large-scale model training • Global synchronization • Massive distributed systems • Elastic compute But it does change the economics and architecture of many applications. Personally, I've adopted a local-first philosophy. If something runs too slowly on my machine, my first instinct isn't to rent more GPUs—it's to optimize the software until it runs efficiently on commodity hardware. That constraint has made me write better software. An interesting consequence is that AI coding agents make this approach even more compelling. Instead of subscribing to another cloud service every time I need new functionality, I can increasingly generate that functionality locally. The question I'm asking more often is no longer: *"How do I scale this in the cloud?"* It's: *"Does this computation actually need to leave the device?"* I think that's going to become one of the defining software architecture questions of the next decade. I'm curious whether others are seeing the same shift, particularly those working with local LLMs, edge AI, or hybrid cloud architectures. ::: This version is written to start a conversation with engineers and technical leaders rather than persuade them outright, which tends to perform better on LinkedIn. It also avoids claims that are easy to dismiss while still presenting a clear thesis.

now write a the original message again combining the two but with the new version made shorter and both versions made shorter so we have paragraphs of text

Here's a condensed version that keeps both ideas but treats the telemetry work as the motivation for the broader architectural insight. :::writing{variant="document" id="21854"} Today was supposed to be the day I began experimenting with a new idea: using website telemetry as another knowledge source for an agentic knowledge graph. Every interaction a visitor has with a website—page views, navigation paths, reading time, scroll depth, referrals—is telemetry. Rather than treating it as charts on a dashboard, I want to export it, construct a behavioral knowledge graph, and use local LLMs to reason over it. Instead of asking, "How many people visited this page?", I want to ask, "What concepts are people looking for?", "What paths lead readers toward my projects?", and "What content should I create next?" Analytics should become something you can have a conversation with. Unfortunately, I spent the entire day trying to get Google Analytics working instead. I had been using Vercel Analytics, which is remarkably easy to configure. Google Analytics offers significantly more flexibility, but getting there feels like navigating a maze of permissions, configuration screens, and integrations. To make matters worse, the final step warns that data may take up to 48 hours to appear, making it difficult to know whether you've fixed the problem or simply haven't waited long enough. While debugging analytics I was also chasing a mobile rendering bug on my Projects page. Somewhere in the middle of all my changes it simply disappeared. I still don't know exactly why, which is one of the more frustrating aspects of debugging complex systems. Eventually I gave up, re-enabled Vercel Analytics, and within minutes telemetry was flowing again. I now have a gap of several days in my data, but at least I have visibility into what visitors are doing while I continue investigating Google's implementation. The experience also reminded me of something larger. Most of my software is built with a local-first philosophy. If something runs too slowly on my laptop, I don't immediately solve the problem by adding more hardware—I optimize it until it becomes efficient enough to run locally. That constraint forces better engineering and lower computational costs. Cloud platforms like Google Cloud, Azure, and AWS are extraordinary pieces of infrastructure, and many workloads genuinely require them. But I think local AI is beginning to change where that boundary lies. Modern edge devices are becoming powerful enough to run sophisticated language models and agentic workflows that previously required cloud infrastructure. I think we're approaching what I call the **Edge Compute Threshold**: the point where local inference becomes capable enough to replace a meaningful portion of what previously required hyperscalers. Cloud computing isn't going away, but its role is changing. Rather than assuming every advanced feature belongs in a data center, we should increasingly ask whether that computation actually needs to leave the device. Ironically, I think designing for edge devices first produces software that scales better. When efficiency is a requirement instead of an afterthought, every optimization matters. If that software is eventually deployed to the cloud, it consumes fewer resources than a system built under the assumption of effectively unlimited compute. The telemetry project I'm working on reflects that same philosophy. My goal isn't simply to collect analytics. It's to build a self-observing information system that can reason about its own evolution using local inference. By combining a knowledge graph of my content with a behavioral graph of visitor interactions, I hope to generate recommendations, discover knowledge gaps, and uncover patterns that traditional dashboards would never reveal. Today wasn't about building that system. It was about building the sensors that will make it possible. ::: I think this version flows more naturally because the telemetry story leads into the broader architectural philosophy instead of feeling like two separate essays stitched together. The debugging experience becomes the catalyst for explaining why you're interested in local-first, self-observing systems in the first place.

try this again but with what I talked about": I see that you work with AI. I myself currently use the deepreinforce-ai_Ornith-1.0-35B-GGUF running on my laptop using either OpenCode or Hermes to vibe code. Yes, I know, I am part of the problem, but vibe coding has been my hobby since I discovered how to do it for free. Well not really for free, I had to invest in a nice Macbook December 2024, but now the coding agents have progressed so far as to be in my opinion superior in terms of results compared to most paid API coding agents. How is that even possible without hyperscalers? I think we have reached a critical threshold where edge devices will be able to use locally hosted coding agents to provide new functionality at will for applications and remove the need for many cloud systems currently. Such as paying for Claude Code. Why pay $200+ a month to slowly lose your ability to code, when you can do that for free with a local coding agent like OpenCode or Hermes. So think of IT services such as remotely accessing another computer to perform technical support. With locally hosted inference and Hermes computer use automations you could get that functionality without even needing an internet connection, although the ability for the agent to use the internet is also essential. My point is, that we have reached a critical mass where the extractive business m

Here's a version that keeps your core idea but sharpens the argument and avoids claims that are difficult to support. It reads more like a thought piece than a rant. :::writing{variant="document" id="36718"} I see that you work with AI. I've gone in a somewhat different direction than many people in the field. For the past several months I've been running local coding agents on my laptop using models like **deepreinforce-ai Ornith-1.0-35B** through OpenCode and Hermes. People call it "vibe coding," and yes, I know that makes me part of the problem. But once I discovered I could do it locally, it became one of my favorite ways to build software. The interesting part isn't that it's free—although after investing in a capable MacBook, there are no per-token API costs. The interesting part is how good the results have become. In many cases, for the type of development I do, the experience is competitive with paid cloud coding assistants. That raises a much bigger question. How is it possible that a laptop can now perform work that, only a few years ago, seemed to require hyperscale infrastructure? I think we've crossed an important threshold. As local language models improve and edge hardware becomes more capable, we're reaching the point where applications can generate new functionality on demand using local inference. Instead of integrating another cloud service or paying another monthly subscription, you can increasingly ask a local coding agent to build the feature for you. That has implications far beyond code generation. Imagine remote IT support. Traditionally, you install remote desktop software, connect to cloud services, authenticate through multiple servers, and rely on an internet connection. But if a local agent has access to computer-use capabilities, many support tasks could happen entirely on the device. Internet access is still valuable for retrieving information or collaborating with others, but the intelligence itself no longer has to live in the cloud. I think this changes the economics of software. For years, the assumption has been that increasingly capable software would require increasingly powerful cloud infrastructure. That created an ecosystem of subscriptions, API pricing, and ever-growing data centers. But what happens when the intelligence can run locally? What happens when your computer can build tools, automate workflows, and extend applications without sending every request to a remote model? Cloud infrastructure will always have an important role. Training frontier models, global collaboration, large-scale distributed systems, and elastic compute aren't going away. But I suspect a growing class of software no longer needs to be cloud-first. Instead of asking, "How do we scale this with more compute?" we may increasingly ask, "Does this computation need to leave the device at all?" If the answer is no, then local-first architectures become compelling—not just because they're cheaper, but because they're faster, more private, more resilient, and owned by the user rather than rented from a provider. I don't think cloud computing disappears. I think its role changes. The future may not belong exclusively to hyperscalers or exclusively to edge devices. It may belong to systems that intelligently combine both—keeping computation local whenever possible and using the cloud only when it provides genuine value. To me, that's one of the most exciting shifts happening in AI today. ::: I also think there's a stronger underlying thesis hiding in your original message: **local coding agents don't just replace cloud coding agents—they can become part of the runtime of applications themselves, dynamically generating functionality on the user's machine.** That's a more novel idea than simply "local LLMs are good," and it's worth developing further.

now write it as a single paragraph and the size of a shorter message to be sent as a DM

Here's a tighter DM that keeps your central idea while sounding conversational rather than like an essay. :::writing{variant="chat_message" id="53184"} I saw that you work with AI, and I've been thinking about something interesting. I've been running local coding agents on my MacBook using OpenCode and Hermes with the deepreinforce-ai Ornith-1.0-35B model. People call it "vibe coding," but what surprises me is how capable these local models have become. For a lot of my development, they're competitive with paid cloud coding assistants. It makes me think we've reached an edge compute threshold where many applications no longer need hyperscalers for their intelligence. Instead of paying $200+/month for API access, a local agent can generate new functionality on demand, automate workflows, and even perform computer-use tasks directly on the device. The cloud will always have a place for large-scale workloads, but I think a growing class of software is going to become local-first. It's a pretty fundamental shift in how I think about software architecture, and I'm curious whether you've been seeing the same trend. :::

try again but instead of ask a question and try to get a response I would rather it be a one time message which references my website that can be sent once without a reply being needed or expected

Here's a version that reads more like a thoughtful introduction than a pitch. It references your website but doesn't ask for a response or create an obligation to reply. :::writing{variant="chat_message" id="62491"} I noticed you work in AI, so I thought I'd share something I've been exploring. I've been building a local-first AI architecture on my website (danielkliewer.com), using local coding agents like OpenCode and Hermes with the deepreinforce-ai Ornith-1.0-35B model running entirely on my MacBook. What's fascinating is that these local models have become capable enough that I increasingly question how much software actually needs hyperscalers. My latest work explores what I call the "Edge Compute Threshold"—the point where edge devices become powerful enough to generate new functionality on demand through local inference, reducing the need for many cloud-hosted services. I think it's an interesting architectural shift, so I figured I'd share it in case it's of interest. :::

no no no, just be technical

:::writing{variant="chat_message" id="17642"} I've been experimenting with local-first agentic architectures on my website (danielkliewer.com). My current setup runs deepreinforce-ai Ornith-1.0-35B locally through OpenCode and Hermes on a MacBook, and it's made me rethink where the boundary between edge and cloud computing actually lies. I think we've reached a point where local inference can dynamically generate application functionality, automate workflows, and perform computer-use tasks that previously required cloud-hosted services. Rather than assuming every intelligent feature belongs behind an API, I'm interested in architectures that maximize local inference and only offload workloads that genuinely require centralized infrastructure. Most of my recent writing and projects revolve around that idea and the implications it has for future software architecture. :::

now another paragraph about my analytics knowledge graph idea

:::writing{variant="chat_message" id="74281"} Another project I'm working on is applying GraphRAG concepts to application telemetry. Instead of treating analytics as dashboards and aggregate metrics, I'm exporting user interaction events, constructing a behavioral knowledge graph, and using local LLMs to reason over it. The goal is to chat with analytics rather than inspect charts—allowing the system to infer user journeys, identify knowledge gaps, recommend content, and discover relationships between concepts and behavior that conventional analytics platforms don't surface. :::

now make this all one small paragraph: I’ve been experimenting with local-first agentic architectures on my website (danielkliewer.com). My current setup runs deepreinforce-ai Ornith-1.0-35B locally through OpenCode and Hermes on a MacBook, and it’s made me rethink where the boundary between edge and cloud computing actually lies. I think we’ve reached a point where local inference can dynamically generate application functionality, automate workflows, and perform computer-use tasks that previously required cloud-hosted services. Rather than assuming every intelligent feature belongs behind an API, I’m interested in architectures that maximize local inference and only offload workloads that genuinely require centralized infrastructure. Most of my recent writing and projects revolve around that idea and the implications it has for future software architecture. Another project I’m working on is applying GraphRAG concepts to application telemetry. Instead of treating analytics as dashboards and aggregate metrics, I’m exporting user interaction events, constructing a behavioral knowledge graph, and using local LLMs to reason over it. The goal is to chat with analytics rather than inspect charts—allowing the system to infer user journeys, identify knowledge gaps, recommend content, and discover relationships between concepts and behavior that conventional analytics platforms don’t surface. Applying LLMs to create knowledge graphs is just kind of fun for me and the kinds of inferences you can produce are quite interesting. Such as I made one with every official text from Catholicism, like the Canon, Magisterium, etc etc. Then once you have the knowledge base you can create loops and automations which can research over the texts and produce finished artifacts such as reports or marketing or financial analysis.

:::writing{variant="chat_message" id="90537"} I’ve been experimenting with local-first agentic architectures on my website (danielkliewer.com). My current setup runs deepreinforce-ai Ornith-1.0-35B locally through OpenCode and Hermes on a MacBook, and it has made me rethink the boundary between edge and cloud computing. I think we’re reaching a point where local inference can dynamically generate functionality, automate workflows, and perform computer-use tasks that previously required cloud services. Another project I’m exploring is applying GraphRAG to application telemetry—turning user interaction events into behavioral knowledge graphs that local LLMs can reason over, allowing analytics to become something you can converse with rather than just inspect. More broadly, I’ve been experimenting with using LLMs to construct knowledge graphs from large text collections, then building automated research loops that can generate artifacts like reports, marketing analysis, or financial analysis from those knowledge bases. The interesting part is seeing what kinds of inferences emerge when information is structured and agents are able to reason over it. :::