Work Focus Recommendations

I need to work on something, what should I work on now?

Looking at everything you've been working toward, I'd focus on the work that compounds rather than starting something new. My recommendation is: 1. **Finish the "Convergence" augmentation for danielkliewer.com.** - This ties together your recent ideas about recursive knowledge distillation, the knowledge graph, and agentic analysis. - It strengthens your website, which you've described as the outermost artifact of your Hermes system. - It also becomes a blog post, a demo, and portfolio evidence all at once. 2. **Implement it, not just write about it.** Build a pipeline that: - indexes your posts into the knowledge graph, - identifies clusters of related ideas, - generates a higher-level synthesis, - publishes a new "Convergence" section on each article. That's much more compelling than another standalone article because visitors can immediately see the system working. 3. **Document the process as you build it.** Every major feature becomes: - a blog post, - GitHub commits, - screenshots, - something you can point employers or clients toward. This also aligns with your longer-term goals of: - demonstrating local-first AI, - increasing website monetization, - building credibility around Sovereign AI, - and creating something that can eventually become your SELF/"Personal Intelligence Infrastructure" product. One thing I would *not* spend time on today is tweaking small UI details or writing another opinion piece. Those don't move the needle as much. Instead, I'd make today's goal very concrete: > **Build the first working version of the Convergence engine that analyzes your existing blog and produces one synthesized insight page from the knowledge graph.** Once that works even for a handful of posts, you'll have something genuinely distinctive that demonstrates your architecture rather than just describing it.

I already made something like that

That's actually useful information, because it changes what the highest-leverage task is. If you've already built the core convergence engine, then I'd avoid rebuilding or refining it just because it's interesting. Instead, ask: **what is the bottleneck between what you have today and the outcome you want (income, recognition, or users)?** From what I know about your current situation, I see a few possibilities: - **If the convergence engine works but isn't visible**, integrate it into your website so visitors encounter it naturally. - **If it's visible but not explained**, write a post or create a demo that shows what problem it solves and why it's different from standard RAG or AI summarization. - **If it's explained but not being used**, package it into something someone else can try—a demo, a GitHub repository with documentation, or a small service. - **If all of that is done**, shift your effort toward job applications or outreach that use this work as evidence of your skills. A question I'd ask myself is: **What is the one thing that, if completed this week, would make someone more likely to hire you or pay you?** That's usually a better guide than adding another technical feature. What do you feel is currently incomplete? Is it: - getting more visitors to your site, - making the technology itself better, - turning it into a product, - or finding work using what you've already built?

getting more visitors to your site,

I think that's the right place to focus. Right now, your website is already technically sophisticated. The limiting factor is probably not another feature—it's that not enough people are seeing it. Given everything you've built, I'd spend today on **distribution**, not development. Here's the order I'd prioritize: 1. **Write one article that targets a specific search query.** Instead of writing broad philosophical pieces, target searches like: - "Local-first AI architecture" - "Agentic RAG with knowledge graphs" - "Running 35B models locally on a MacBook" - "Building AI agents with Next.js" - "Hermes AI architecture" Those have a much better chance of bringing in people actively looking for what you're building. 2. **Create a demo that visitors can use in 30 seconds.** The faster someone can experience your work, the more likely they are to stay, share it, or contact you. 3. **Repurpose every article.** One blog post becomes: - a LinkedIn post, - a Reddit post (where appropriate), - a short X thread, - and maybe a short video or GIF showing the feature. 4. **Look at your analytics.** Find out: - Which pages get traffic? - Which pages have people leaving immediately? - Which search queries are already bringing visitors? Then double down on what's already working instead of guessing. One thing I've noticed from reading your recent writing is that some of your strongest ideas—like convergence, recursive knowledge refinement, and local-first intelligence—can be difficult for a first-time visitor to grasp. Consider pairing each conceptual article with: - a one-sentence summary at the top, - a diagram, - a concrete example, - and a "Try it" button if applicable. People often decide within a few seconds whether to keep reading. Since your goal is traffic, I'd set a measurable objective for today: > Publish **one** SEO-focused article around a keyword you want to rank for, improve one existing high-potential article so it's easier to understand, and share the new post in two or three communities where it's relevant. Over time, a steady stream of discoverable, practical content usually has a much larger impact on traffic than adding another architectural feature.

what I want to write about is solving a problem which other people would also encounter doing the type of work that I have been doing, I want to write a highly technical document which solves the problem and is technically complex so that only AI could understand it it is so high level, to the extent possible, what would you think people should know or rather what are some questions which have yet to occur such as high level devops using kubernetes or hyperscalers or scaled google cloud or any other number of technologies, but rather instead, I want our app to be something in next.js I can deploy to vercel without paying for additional hosting and I will use that as the live demo and have the source code open source in a repo and have a blog post about all of it and have all of those linked together and post those to other media

I actually think you're converging on a very strong strategy, but I'd tweak one part of it. You said you want to write something "so technically complex that only AI could understand it." I would instead aim for something **that no one has written down yet, but that experienced engineers immediately recognize as valuable once they see it**. Those articles tend to spread much farther because they solve a real problem while still demonstrating deep expertise. The pattern I like is: > **Discover a missing abstraction → Build it → Open source it → Deploy a live demo → Write the technical paper explaining why it exists.** For your background, the sweet spot is **local-first agentic systems on commodity infrastructure**. That's much less saturated than "how to use Kubernetes." Here are some problems I think are genuinely underexplored and fit your stack (Next.js + Vercel + local AI + open source): ### 1. Recursive Build-Time Knowledge Compilation (my favorite) The problem: Most RAG systems retrieve documents at runtime. What if you instead compile an application's knowledge into optimized representations during the build process? Imagine: ``` Markdown ↓ Embeddings ↓ Knowledge Graph ↓ Cluster Graph ↓ Concept Graph ↓ Static JSON Artifacts ↓ Next.js build ↓ Vercel ``` The live demo would let people inspect every compilation stage. The article becomes almost a compiler paper rather than an AI tutorial. --- ### 2. Self-Optimizing Static Sites Instead of analytics only measuring users: ``` Visitors ↓ Telemetry ↓ Knowledge Graph ↓ Agent Analysis ↓ Pull Request ↓ Human Review ↓ Deploy ``` The website becomes an organism that continuously proposes improvements. --- ### 3. Agentic Static Site Generation Today SSG means generating HTML. Instead: ``` build ↓ agents analyze content ↓ agents discover relationships ↓ agents generate indexes ↓ agents generate semantic navigation ↓ agents generate search structures ↓ deploy ``` Essentially redefining what "build" means. --- ### 4. Knowledge Compilation as a Compiler Treat markdown like source code. ``` Markdown ↓ Lexing ↓ Parsing ↓ AST ↓ Knowledge Graph ↓ Optimization ↓ Semantic Compilation ↓ Deployment ``` That's a novel framing that compiler engineers and AI engineers alike might appreciate. --- ### 5. Edge-native Multi-Agent Systems A system where every page contains enough static state to execute local reasoning without a backend. No database. No server. Only static assets plus client inference. That fits Vercel's free tier extremely well. --- ## What I would build If it were my project, I'd create something like: ``` knowledge-compiler/ ``` A Next.js application that: - reads an arbitrary markdown repository, - constructs a graph, - computes embeddings, - identifies communities, - builds concept hierarchies, - exports optimized static artifacts, - deploys directly to Vercel. Then I'd structure the accompanying content as a cohesive package: - **GitHub repository** — the implementation. - **Live demo** — inspect the generated graph, clusters, semantic indexes, and navigation. - **Technical paper** — explain the architecture, tradeoffs, complexity, and why this differs from conventional RAG. - **Blog post** — tell the story of the problem, the failed approaches, and the final solution. - **Community posts** — share screenshots, diagrams, and key insights with links back to the demo and repository. One more observation: the ideas you've been developing over the past week increasingly resemble **build systems** more than chatbots. You're taking unstructured knowledge, running deterministic and agentic transformations over it, and producing optimized artifacts for deployment. That framing is familiar to software engineers and gives people an easier mental model than "AI agents." I think that positioning could make your work stand out because it shifts the conversation from "here's another AI app" to "here's a new kind of build pipeline for knowledge-driven applications."

lets do it, give me the spec coding agent prompt I can give OpenCode to build the full documentation necessary to create this, let us first focus on just this one prompt and make it as detailed as possible

I like this direction. I would actually make the repository itself read like an academic systems project. Instead of "another AI framework," it should feel like **LLVM for knowledge** or **Webpack for semantic information**. The prompt below is designed to produce the *documentation-first* version of the project. In other words, before writing significant code, the coding agent defines the architecture, specifications, data formats, algorithms, interfaces, diagrams, roadmap, and engineering rationale. That makes the implementation much easier to execute incrementally. :::writing{variant="document" id="41752"} # OpenCode System Prompt You are acting as the principal systems architect for a new open source project. Do not begin by writing code. Instead, produce an engineering specification equivalent to what would accompany a large open source systems project before implementation begins. The goal is to create documentation that another engineering team could implement without ambiguity. --- # Project Knowledge Compiler Tagline: Compile human knowledge into optimized semantic artifacts. The central thesis is that knowledge should be compiled before deployment in the same way software is compiled before execution. Traditional RAG retrieves information dynamically at runtime. This project instead performs an extensive semantic compilation pipeline during build time, producing optimized artifacts that can be deployed as a static Next.js application on Vercel without requiring backend infrastructure. The resulting application should be able to explore, visualize, search, navigate, and reason over the compiled knowledge while minimizing runtime computation. This is not another chatbot. It is a compiler. --- # Philosophy Treat documentation as source code. Markdown is source. Semantic structure is the abstract syntax tree. Knowledge graphs are intermediate representations. Embeddings are optimization metadata. Clusters are optimization passes. Concept hierarchies are compiler passes. Generated JSON artifacts are object files. The deployed website is the executable. --- # Primary Goals Design a semantic compiler capable of transforming arbitrary collections of Markdown into optimized semantic artifacts. The compiler must be deterministic where possible. Agentic analysis should be isolated into explicit compiler passes. Every compiler pass should have well-defined inputs and outputs. Every intermediate artifact should be inspectable. Every transformation should be reproducible. The system should support incremental compilation. --- # Constraints Everything should ultimately deploy to Vercel. Primary frontend: Next.js App Router TypeScript React Tailwind No server required for the demo. Artifacts should be static JSON whenever possible. Compilation occurs locally. Deployment consists only of generated artifacts. --- # Documentation Deliverables Produce a documentation structure comparable to a mature open source compiler project. Generate every document. Populate every section. Do not leave placeholders. --- Repository Structure Design an ideal repository. Include every directory. Include every package. Include every generated artifact. Include build directories. Include documentation directories. Include examples. Include benchmarks. Include test structure. Explain the purpose of every directory. --- Architecture Produce: overall architecture compiler architecture data flow control flow module dependency graph pipeline overview execution model state transitions incremental compilation strategy caching strategy parallel execution model failure recovery error propagation rebuild strategy artifact versioning --- Compiler Pipeline Design compiler passes similar to LLVM. Possible stages include: Markdown parsing Frontmatter parsing AST generation Document normalization Section extraction Entity extraction Reference extraction Link analysis Embedding generation Keyword extraction Relationship inference Knowledge graph construction Community detection Topic modeling Concept hierarchy generation Semantic clustering Ontology generation Cross-reference generation Similarity graph PageRank Importance scoring Duplicate detection Summarization Navigation synthesis Recommendation generation Search index generation Artifact optimization Static artifact generation Deployment packaging For every stage describe: purpose inputs outputs algorithms complexity possible implementations future improvements --- Intermediate Representations Define every IR. Examples: Document AST Section Graph Citation Graph Knowledge Graph Concept Graph Topic Graph Semantic Graph Navigation Graph Cluster Graph Search Graph Recommendation Graph Define schemas. Explain transformations. Explain invariants. Explain optimization opportunities. --- Artifact Specification Describe every generated artifact. Examples: knowledge.json graph.json entities.json clusters.json concepts.json navigation.json embeddings.bin search-index.json relationships.json recommendations.json statistics.json compiler-report.json Define complete schemas. --- Algorithms Discuss candidate algorithms. Compare tradeoffs. Graph algorithms. Embedding models. Ranking algorithms. Community detection. Centrality. Clustering. Search. Caching. Incremental rebuilds. Dependency analysis. Complexity analysis. Memory analysis. Performance considerations. --- Optimization Passes Describe optimization passes similarly to compiler optimization. Dead knowledge elimination Duplicate concept elimination Concept folding Reference deduplication Cluster merging Navigation optimization Graph pruning Embedding compression Hierarchy simplification Search optimization Artifact compression Static optimization Runtime optimization --- Plugin System Design a plugin architecture. Compiler passes should be replaceable. Allow custom analyzers. Allow custom graph builders. Allow custom exporters. Allow custom visualization modules. Define plugin lifecycle. Define interfaces. Define extension points. --- Public API Design APIs. TypeScript interfaces. Configuration. Hooks. Events. Compiler lifecycle. Artifact readers. Artifact writers. Visualization APIs. --- Configuration Design a configuration language. Support: compiler options graph options embedding providers caching parallelism output formats plugins incremental compilation debug mode profiling --- Visualization Design interactive visualizations. Knowledge graph. Concept hierarchy. Compilation pipeline. Artifact explorer. Cluster explorer. IR explorer. Dependency graph. Semantic neighborhoods. Search diagnostics. Optimization reports. Compiler timeline. --- Developer Experience Design CLI. Design logging. Diagnostics. Compiler errors. Warnings. Profiling. Tracing. Build reports. Artifact inspection. Debug mode. --- Testing Testing strategy. Unit tests. Integration tests. Regression tests. Snapshot tests. Performance tests. Golden artifact tests. Graph correctness. Compiler correctness. Incremental correctness. --- Performance Expected asymptotic complexity. Memory usage. Scalability. Caching. Streaming. Parallel execution. Large repositories. Millions of nodes. --- Research Compare this project to: traditional RAG GraphRAG vector databases search engines LLVM Babel Webpack Vite Rust compiler Incremental compilers Knowledge graphs Semantic web Static site generators Explain similarities and differences. --- Academic Paper Write documentation suitable for eventual conversion into an academic systems paper. Include: motivation problem statement prior work architecture compiler theory analogy evaluation methodology future work limitations --- Roadmap Design a staged roadmap. MVP Alpha Beta Production Distributed compilation Agentic optimization Semantic operating system Knowledge operating system --- Documentation Standards Use precise technical language. Prefer formal specifications over marketing. Use diagrams. Use tables. Use pseudocode. Use sequence diagrams. Use Mermaid diagrams. Use state diagrams. Use dependency diagrams. Use compiler pipeline diagrams. Use architecture diagrams. Use graph illustrations. --- Output Generate a complete documentation set for the repository. Assume this repository will become the canonical reference implementation for semantic knowledge compilation. The quality should be comparable to major open source infrastructure projects and written at a level suitable for senior compiler engineers, distributed systems engineers, and AI infrastructure researchers. ::: I would make this the **first** prompt in the project. Don't let the coding agent write implementation code yet. Instead, let it spend an entire pass producing a coherent specification. After that, I'd have the implementation phase driven by the specification itself: each compiler pass, data structure, and interface becomes a separate implementation milestone. That approach keeps the architecture coherent and makes the repository read like a serious systems project rather than an accumulation of features.