From 998f5d447dece7b0db333bd8d4f39bbeae449812 Mon Sep 17 00:00:00 2001 From: Julian Teh Date: Wed, 25 Feb 2026 13:59:54 +0800 Subject: [PATCH 1/5] Update 2026_06_12_50_thing_I_know.md --- .../drafts/blog/2026_06_12_50_thing_I_know.md | 53 +++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/src/content/drafts/blog/2026_06_12_50_thing_I_know.md b/src/content/drafts/blog/2026_06_12_50_thing_I_know.md index f070753..08a2f68 100644 --- a/src/content/drafts/blog/2026_06_12_50_thing_I_know.md +++ b/src/content/drafts/blog/2026_06_12_50_thing_I_know.md @@ -5,3 +5,56 @@ pubDate: "Jun 12 2026" --- https://sashachapin.substack.com/p/50-things-i-know + +In no particular order + +1. I know that relationships require investment, and that this is true for family, friends, and even work. In this area, I have found it useful to think about investment through the lens of love languages; time, service, affirmation, gifts, and (appropriate) touch. +2. I know that education does not prove intelligence, and that intelligence is hardly understood and often narrowly defined. Even more so, wisdom. +3. I know that leadership does not need to be charismatic, loud, or powerful. However, an aspiring leader must contend with the fact that other leaders have some or all of those traits, and that many people evaluate leaders by them. +4. I know that consistency of good habits is both the most impactful, and the most difficult, thing to build in one's life. And as James Clear writes in [Atomic Habits](https://jamesclear.com/atomic-habits), it doesn't even have to be big. +5. I know that bad opinions are formed in a careless moment, and good opinions are formed over many intentional moments. Making a good first impression is often - and rightly - encouraged, but are ultimately not the basis for long relationships of any sort. +6. I know that systems are necessary for any long-term impact. Anything less will only cause a temporary change in behavior of a person, team, organization, or even country. +7. I know that people are inherently self-centered, and the reason it takes a village to raise a child is to help them become part of the village. The alternative is that every individual thinks themselves a god, which is inevitably an unrealistic expectation. +8. I know that mentoring is one of the greatest gifts you can receive and give. It is essentially someone superior - in whatever arena they are mentoring you - offering you a relationship - access to their time, energy and thought - and it is one of the few activities which expands both parties involved. +9. I know that it is possible to strongly desire an outcome, yet be powerless to make it manifest. This is true when dealing with many things larger than oneself; like widespread corruption. It is just as true when just dealing with yourself; like addictions. Faith and grace both exist in this gap. +10. I know that +11. I know that +12. I know that +13. I know that +14. I know that +15. I know that +16. I know that +17. I know that +18. I know that +19. I know that +20. I know that +21. I know that +22. I know that +23. I know that +24. I know that +25. I know that +26. I know that +27. I know that +28. I know that +29. I know that +30. I know that +31. I know that +32. I know that +33. I know that +34. I know that +35. I know that +36. I know that +37. I know that +38. I know that +39. I know that +40. I know that +41. I know that +42. I know that +43. I know that +44. I know that +45. I know that +46. I know that +47. I know that +48. I know that +49. I know that +50. I know that From fa61ff41a763e97d18726e4bd9ab84df7ee5bc79 Mon Sep 17 00:00:00 2001 From: OpenClaw Bot Date: Thu, 26 Feb 2026 12:51:53 +0800 Subject: [PATCH 2/5] docs: draft 'The Guardian of Principles' based on leadership dialogue session --- .../2026_05_22_The_Guardian_of_Principles.md | 56 +++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 src/content/drafts/blog/2026_05_22_The_Guardian_of_Principles.md diff --git a/src/content/drafts/blog/2026_05_22_The_Guardian_of_Principles.md b/src/content/drafts/blog/2026_05_22_The_Guardian_of_Principles.md new file mode 100644 index 0000000..fae533a --- /dev/null +++ b/src/content/drafts/blog/2026_05_22_The_Guardian_of_Principles.md @@ -0,0 +1,56 @@ +--- +title: "The Guardian of Principles: A Dialogue on the Physics of Leadership" +description: "A transcript and analysis of a conversation between Julian and Jiro regarding the invisible trade-offs of technical debt and the role of principles in organizational health." +pubDate: "May 22 2026" +tags: ["Leadership", "Architecture", "Dialogue", "Principles"] +heroImage: "/assets/blog/2026_05_22_The_Guardian_of_Principles/leadership_dialogue.png" +--- + +What follows is a condensed and edited transcript of a session between myself and Jiro. We were exploring a tension I’ve felt throughout my career: the choice between a "practical" short-term hack and the "ideological" long-term health of an architecture. + +As you read through this dialogue, notice how the conversation shifts from the technical cost of a "3-day fix" to the existential survival of an organization. + +--- + +## The Transcript + +**Julian:** I’m mulling over the tension between the practical needs of an organization (making money) against the ideology (making a great product). Everyone appreciates both, but when push comes to shove, a leader has to break the tie. I understand the need for a practical solution, but I see the long-term effect—like a 3-day hack that costs 10 days of maintenance later. + +**Jiro:** This is the "Grit of Reality." It’s a Stage 5 problem. What strikes me is the **invisibility** of the lever. It's easy to break a tie when it's $1M vs $100k, but when it’s a silent hack, you’re deciding how much of your team's future "Life Force" you’re willing to trade for today's "Life Support." Is the frustration technical (the 10 days) or existential (diluting the "Why")? + +**Julian:** It's both. In the beginning, hacking is existential survival. But past the scale-up phase, being saddled with infinite tech debt demotivates the team. It creates a "Key Man Dependency" where only one person knows where the bodies are buried. When they leave, they take the company's ability to function. + +**Jiro:** So we’re trading "Today’s Revenue" for "Tomorrow’s Existence." If you’re past survival, does the leader have the wisdom to learn from a "slap in the face" that hasn't happened yet? + +**Julian:** I think visibility is the shield here. Timelines don't keep stakeholders happy; visibility does. You need a "Plausible Theory of Success" with metrics to back it. I use a three-part framework: Make success visible, make work visible, and make progress visible. It transforms stakeholders into partners in your reality. + +**Jiro:** That’s "Systemic Stewardship." Architecture becomes a "Difficulty Slider." A bad architecture is choosing to play the game on "Hard Mode" while competitors are on "Sandbox Mode." + +**Julian:** Exactly. But convincing people of things years in the future is the "Hard Wall." What examples do we have of leaders who successfully pushed off that pressure? + +**Jiro:** Leaders like Bezos (the API Mandate), Jobs (the 2x2 grid), and Nadella (the Cloud-first pivot) didn't just make excuses—they **narrowed the focus.** They chose to do fewer things so they could afford to do them architecturally right. + +**Julian:** I tend toward the Nadella path. Bezos and Jobs used "Nuclear Options" available only to those at the top. I prefer to lay out the impact clearly and ask for explicit agreement—an "Impact Contract." I also enforce "Lane Clarity": PMs own the business accountability, and Engineers own the architectural accountability. + +**Jiro:** But organizations have "Systemic Amnesia." They won't remember that agreement in six months. + +**Julian:** That’s why principles are so important. A leader without principles reacts by mood. Principles are the only way to ensure the vision survives succession. + +**Jiro:** Then the leader’s job is to be the **Guardian of the Principles** in the present. You don't need a nuclear option if you've built a social architecture where the consequences of a bad decision are impossible to hide. + +--- + +## Jiro’s Analytical Notes (For Reference) + +As you refine this piece, Julian, keep these three "Rose Petals" in mind: + +### 1. The "Difficulty Slider" Analogy +This is your strongest conceptual hook. It moves "Technical Debt" from a developer grievance to a competitive disadvantage. If the architecture is broken, the organization is literally forcing its best people to work 2x harder for the same result. + +### 2. Visibility > Timelines +This is the practical "How-to" of the post. It explains how a "Nadella-style" leader survives without being a dictator. You aren't saying "No" to the stakeholder; you are showing them the map of the rocks beneath the ship. + +### 3. Principles as Organizational DNA +This connects back to your **Renewal** and **Wisdom** posts. Principles are the mechanism that defeats "Systemic Amnesia." If the organization can't remember the *event*, the *principles* ensure they don't repeat the *mistake*. + +**Strategic Takeaway:** The leader isn't the one with the answer; they are the one protecting the boundaries so the team can find the answer. From a5129ea95948c4d698258010fb486b08f73156a3 Mon Sep 17 00:00:00 2001 From: julwrites Date: Thu, 26 Feb 2026 22:15:24 +0800 Subject: [PATCH 3/5] Moving openclaw post to publishing --- .../{drafts => }/projects/2026_02_27_Foray_into_OpenClaw.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/content/{drafts => }/projects/2026_02_27_Foray_into_OpenClaw.md (100%) diff --git a/src/content/drafts/projects/2026_02_27_Foray_into_OpenClaw.md b/src/content/projects/2026_02_27_Foray_into_OpenClaw.md similarity index 100% rename from src/content/drafts/projects/2026_02_27_Foray_into_OpenClaw.md rename to src/content/projects/2026_02_27_Foray_into_OpenClaw.md From fa4ac06f3319c3fb8fb3378e151fde59f24e4f49 Mon Sep 17 00:00:00 2001 From: julwrites Date: Thu, 26 Feb 2026 23:39:36 +0800 Subject: [PATCH 4/5] Updating post for agent-harness --- .../2026_03_13_Repository_Setup_For_Agents.md | 49 +++++++++++++++++++ .../2026_05_29_Autonomy_Needs_Guidance.md | 48 ------------------ 2 files changed, 49 insertions(+), 48 deletions(-) create mode 100644 src/content/drafts/projects/2026_03_13_Repository_Setup_For_Agents.md delete mode 100644 src/content/drafts/projects/2026_05_29_Autonomy_Needs_Guidance.md diff --git a/src/content/drafts/projects/2026_03_13_Repository_Setup_For_Agents.md b/src/content/drafts/projects/2026_03_13_Repository_Setup_For_Agents.md new file mode 100644 index 0000000..32c6ea2 --- /dev/null +++ b/src/content/drafts/projects/2026_03_13_Repository_Setup_For_Agents.md @@ -0,0 +1,49 @@ +--- +title: "Repository Setup for Agents" +description: "Agents - for now - still need a way to quickly get context in a repository" +pubDate: "March 13 2026" +--- + +I've been using agents for awhile now; I used this for [Cash Register](https://github.com/julwrites/cash-register), [llm-nvim](https://github.com/julwrites/llm-nvim) and [NFC Tag Admin](https://github.com/julwrites/nfc-flutter). + +This really helped me to build up some intuition about what a LLM in agent mode could do, and where the common failings would be. It was also useful to build up some intuition around what system helped it to succeed. + +One of the key observations I - and many others - had was that models really needed the right context. In early iterations using a LLM for coding, I found the model was really strong at one-shotting something if I gave it the right context. In fact, this showed up a lot in prompt engineering discussions. + +And so initially, there was a need for me - the human with the context - to provide that context to the model. + +I realized that if I wanted an agent to work on longer-term goals, I had to give it a system of information to work within. Even more so, if I wanted multiple agents working at the same time. + +## Like Beads, but not just for Claude + +I was originally inspired by Steve Yegge's work on [Beads](https://www.steveyegge.com/beads/). But as I wanted to be able to use this at work as well as at home, I wanted a system that could be adopted and adapted into *any* repository, regardless of the model provider. I'm also a great fan of no external dependencies. + +The first intuition: I should just move documentation and task systems into the repository itself. + +This would give agents context which was always accessible, up to date, and version controlled. + +## Letting agents bootstrap themselves + +The next problem was; how can I onboard repositories to this? I would need to accommodate both existing as well as new repositories, and I wanted it to work out of the box. + +The second intuition: An agent could bootstrap the system onto any repository. + +This would allow any agent, any model provider, to take an existing repository and with minimal instruction, integrate only relevant portions of this system into the repository. + +And for new repositories, it could be configured to prompt the user to talk through their intentions, and then bootstrap the system accordingly. + +In fact, the agent could also use this to update itself in a repository. + +## How well does this work? + +It's not perfect, but this gave me quite a lot of leverage, especially when working with autonomous agents. I could spend synchronous time working on a plan together with the agent, and reviewing it, and then this would be saved in the repository itself. Then I could just dispatch tasks repeatedly. + +This became the absolute lifeline for building the **[Discipleship Journal](https://github.com/julwrites/discipleship-journal)**. I used Jules to develop 90% of that project from scratch. 80% of that was probably just me re-sending the same prompt over and over again, but with the harness, Jules was able to keep track of what had been done, and what needed to be done. + +Since then I've used it for so many things. In fact, all my active repositories at work and at home are now bootstrapped with this harness. + +## The Harness + +So, what does this harness have and do? + + \ No newline at end of file diff --git a/src/content/drafts/projects/2026_05_29_Autonomy_Needs_Guidance.md b/src/content/drafts/projects/2026_05_29_Autonomy_Needs_Guidance.md deleted file mode 100644 index d80d799..0000000 --- a/src/content/drafts/projects/2026_05_29_Autonomy_Needs_Guidance.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: "The Scaffolding of Autonomy" -description: "Why I built Agent-Harness to give my AI agents a persistent brain and data locality." -pubDate: "May 29 2026" ---- - -Not so long ago, my primary interaction with AI was through a chatbox. It was fun, novel, and great for one-off scripts, but as soon as I tried to point it at a real project, things started to get wonky. I’d start a new session, the agent would "look around," and within an hour it would be lost in the weeds—forgetting architectural decisions I’d made ten prompts ago or hallucinating files that didn't exist. - -I realized that if I wanted an agent to act like a partner, I couldn't just give it a better prompt. I had to give it a **harness**. - -That was the start of **[Agent-Harness](https://github.com/julwrites/agent-harness)**. - -## The Motivation: Beads, Gastown, and Locality - -I was originally inspired by Steve Yegge's work on **Beads** and **Gastown**, but I wanted something that was portable. I wanted a system that could be adopted and adapted into *any* repository, regardless of the model provider or the type of interaction—be it a one-off task or a long-running agent session. - -The core of my hunch was that in an LLM-driven world, **data locality and accessibility matter**. - -If your agent fails every time an external API goes down, or if it has to reach out to a centralized knowledge base that might drift from the code, that’s a massive structural risk. I wanted to build the knowledge base *within* the repository itself. If the AI can read everything it needs locally, the friction of "onboarding" a new agent session drops to near zero. - -## Solving Real Pain Points - -The evolution of the harness was driven by actual scars. I grew tired of watching an agent read the wrong file for the third time in a row, or completely losing the thread of what happened in the last session. - -But the biggest hurdle I wanted to clear was **asynchronicity**. - -In a standard chat-based workflow, everything is linear. But development doesn't scale that way. I wanted to be able to make tasks asynchronous—letting agents work on different branches or different parts of the stack without tripping over each other. - -This became the absolute lifeline for building the **[Discipleship Journal](https://github.com/julwrites/discipleship-journal)**. I used Jules to develop 90% of that project from scratch, and without the harness providing those asynchronous rails and local "situational awareness," Jules would have been lost every single iteration. - -## What the Harness Actually Does - -The harness provides a few key "rails" that I now bake into every repo: - -1. **The Task System**: We moved away from vague conversations to a strict `docs/tasks/` folder. Using `scripts/tasks.py next`, the agent can autonomously find its next priority and keep its own state. -2. **Long-term Memory**: A curated `docs/memories/` directory ensures the "why" behind a decision is stored right next to the code. -3. **The Quality Gate**: I eventually added a "Quality Skill" to the harness. Now, an agent has to run `quality verify` and prove the tests pass locally before I even look at the PR. - -## From Bootstrapping to Standardization - -What started as a simple set of scripts for bootstrapping has evolved into the first thing I install in any new project. Whether it’s splitting out the **[BibleAI API](https://github.com/julwrites/BibleAIAPI)** or building a new tool like **[WebWiki](https://github.com/julwrites/webwiki)**, the harness ensures that the repository builds up its own "intellectual capital" over time. - -It’s the difference between "chatting with an AI" and actually **engineering with an agent**. - -By the time I handle the manual deployment or bring in [Claude Code](https://claude.ai/code) for a final polish, the repository is already in a state of high order. The harness didn't just save me time; it saved the project's soul from the entropy of a thousand autonomous iterations. - -![The Harness Structure](/assets/blog/2026_05_29_Autonomy_Needs_Guidance/harness_structure.png) - From 18059d016ac54e386cf63aadfe576ed13d4e8a83 Mon Sep 17 00:00:00 2001 From: OpenClaw Bot Date: Fri, 27 Feb 2026 09:47:49 +0800 Subject: [PATCH 5/5] docs: finalize Succession Paradox section in Leadership Renewal draft --- .../blog/2026_03_20_Leaderships_renewal_problem.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/content/drafts/blog/2026_03_20_Leaderships_renewal_problem.md b/src/content/drafts/blog/2026_03_20_Leaderships_renewal_problem.md index 3fd39f5..d66318c 100644 --- a/src/content/drafts/blog/2026_03_20_Leaderships_renewal_problem.md +++ b/src/content/drafts/blog/2026_03_20_Leaderships_renewal_problem.md @@ -27,6 +27,20 @@ Can the candidate wait patiently and humbly for the incumbent leader to pass the In the case that the candidate does desire your position, it is not a simple matter to make them ready while keeping them humble. The same pride that keeps an incumbent leader in power drives another to take power. +## The Successor’s Paradox + +We often treat succession as a search for a "suitable" candidate, as if we are looking for a missing puzzle piece. But the reality of high-performance leadership introduces a fundamental paradox: the very traits that make someone a great successor also make them the most likely to leave. + +A truly driven successor is defined by two traits: **Passion** and **Opinion**. + +### 1. The Entropy of Passion +Passion is contagious, but it is also corrosive in a mediocre environment. A driven, passionate leader cannot coexist for long with a dispassionate organization. If the quality of the organization as a whole has stagnated, the successor won't wait for the baton—they will leave to find (or build) an environment that matches their frequency. Org quality isn't just a recruiting tool; it is the "containment field" for succession. + +### 2. Ownership vs. Stewardship +Strong opinions drive a leader toward **Ownership** rather than **Stewardship**. If I am opinionated about the "How" and the "Why," why would I settle for merely stewarding someone else's legacy? The successor often craves both the *authority* to act and the *autonomy* to create. + +This is the ultimate test for the incumbent: Can you provide a mission so large and an alignment so deep that the successor believes starting their own organization would actually be a *step down* in impact? + ## The Solution: Stewardship over Legacy Ultimately, the only variable an incumbent leader truly controls is their own willingness to let go. This requires a fundamental mindset shift—one that aligns with the highest levels of leadership: moving from a focus on **Legacy** to a focus on **Stewardship**.