This blog is not meant to be a general AI news feed.
It is my operating manual.
I use it to document the workflows, product decisions, launch lessons, and mistakes that actually matter when you are trying to build practical AI systems inside Obsidian without losing control of the work.
What you will find here
I publish four kinds of posts most often.
The first is workflow essays: the repeatable systems I use for writing, review, research, and production.
The second is product notes: the features I add to SystemSculpt because a real workflow kept getting stuck somewhere.
The third is operator guidance: the checks, approval models, and decision rules that keep AI work from becoming an ungoverned mess.
The fourth is business implementation writing: the service and AgentOps side of this work for teams that need the workflow built, not just described.
That means this blog sits between SystemSculpt Pro, the docs, and the workflow build path. It is where I explain why the system exists the way it does.
How I think readers should use this blog
I do not think the best way to read this site is to bounce around randomly.
I would pick a lane first.
If you are here because you want to build inside your own vault, start with the product and workflow side: SystemSculpt Pro, the docs, and one workflow you can actually run this week.
If you are here because you need a governed implementation path for a business workflow, start with the workflow build offer.
If you are still figuring out how you think about the work itself, start with the essays and workflows. The Project Spec From Scattered Notes guide is a good example of the level I care about: practical, constrained, and built for real execution rather than inspiration.
What I care about when I write here
I care much more about durable systems than impressive demos.
That shows up in the posts.
I am usually asking some version of the same questions:
- what part of the workflow is actually compounding
- where approvals belong
- what the operator should still control directly
- how the system gets better after repeated use
I do not want this blog to be full of vague enthusiasm about AI. I want it to help someone make better implementation decisions.
That is why the writing tends to come back to structure, ownership, review loops, and concrete next steps.
Where I would start in the first week
If you are new here, I would keep the first week simple.
Read one writing or workflow piece, then install one path you can actually use.
For most self-serve readers, that means starting with the docs, the prompts, or one workflow from /workflows, then using approvals on a real file change before adding more complexity.
For operators evaluating the services side, it means getting clear on one outcome, one owner, and one workflow boundary before trying to automate a whole department.
The point is not to consume everything on the site. The point is to turn one part of it into a working loop.
Why this post stays noindex
I keep this welcome post as a routing layer more than a search asset.
It is useful for orientation, but it is not the sharpest page for any one topic. The better destination is usually one of the more specific posts or workflows, because those pages carry a clearer promise and a clearer next step.
So I treat this as a guidepost:
- if you want product access, go to SystemSculpt Pro
- if you want setup and operating detail, go to the docs
- if you want done-with-you implementation, go to workflow build
My preferred next step
I would not try to absorb the whole site in one sitting.
Choose the path that matches how you actually work right now.
If you want to build inside your vault, start with SystemSculpt Pro and the docs.
If you want me to help build the workflow with you, go to the workflow build path.
And if you just want to understand how I think about these systems, keep reading the blog. That is what it is here for.
