I want my public writing to make it easier for people to understand the engineering work I care about: AI agents, security, and reliable systems. That means explaining decisions, showing what broke, and leaving enough evidence for someone else to check the result.

The difficult part is producing something worth explaining. A publishing system should make room for that work.

This is the approach I want to build around my website, GitHub, LinkedIn, and Substack. It starts with a technical question and ends with something another engineer can use. Automation helps with the work between those points. Publication remains my decision.

Start with a question that can produce evidence

“Write about agent reliability” is too broad to guide an investigation. “What happens to an agent’s tool calls when its process restarts halfway through a task?” gives me something to test.

That question creates several possible lines of inquiry. Does the agent repeat an action that already succeeded? Can it distinguish a failed request from a successful request whose response was lost? What survives in its checkpoint? Which decisions belong in deterministic code?

A useful result could be a small test harness, a failure trace, and a description of the recovery behavior. Even a negative result matters if the test exposes a limitation someone else might otherwise discover in production.

This is a hypothetical investigation, not a benchmark result. The distinction matters. A plausible experiment plan gives me no license to write a measured conclusion.

I want a backlog of questions at this level of specificity. Each entry should identify the intended reader, the decision the answer would help them make, the evidence required, and the cost of getting it. A topic that needs weeks of infrastructure should compete honestly with one I can investigate using code I already have.

Keep the claim attached to its evidence

A chart with a confident title can hide a weak comparison. Before packaging a result, I need to be able to explain how it was obtained.

For an experiment, that means recording the relevant code revision, environment, inputs, baseline, measurements, and failure cases. For an architecture teardown, it means pointing to the code or documentation behind the explanation. An interpretation should be identifiable as an interpretation.

The restart investigation, for example, would need a precise definition of a repeated action. Repeating a read and repeating a payment have different consequences. A synthetic tool with a recorded side effect would let me test the recovery behavior without touching a real account. I would also need to distinguish what the agent attempted from what the tool actually committed.

Those details determine what the result means. They belong in the published methodology, even if the short social post links to a longer explanation.

External research deserves attribution. Firsthand experience needs to be real. If I have only inspected a repository, I should say that rather than imply I operated the system under production load. Private employer information and customer data stay outside the publishing pipeline unless their use is explicitly authorized.

Leave behind an artifact

I want each substantial investigation to improve something that survives the announcement.

Sometimes that will be a repository with a reproducible test. Sometimes it will be a diagram that explains a trust boundary, an annotated trace, or a checklist someone can use during a design review. The artifact should match the question. A repository containing only a README is not automatically better than a clear, well-supported article.

For the restart example, I would aim to leave a runnable failure scenario and a short account of what it demonstrates. Another engineer should be able to change the persistence strategy and see whether the behavior changes. That is more useful than asking them to trust my summary.

An artifact also makes the limits of the work visible. Readers can inspect the setup, point out an unrealistic assumption, or suggest a harder case. A correction can improve the next version of the experiment.

Give each channel a useful job

The website can hold the full explanation: methodology, findings, limitations, references, and links to the code. GitHub can hold the implementation and reproduction instructions.

LinkedIn needs a smaller unit. One finding, one useful visual, enough context to understand it, and a route to the underlying work. A PDF carousel makes sense when the explanation depends on a sequence. A single chart or a short text post may do the job better when the result is simple. I don’t want to stretch a finding to fill a slide count.

Substack can carry a longer synthesis across investigations: what changed in my understanding, which questions remain open, and how the findings connect. At the start, I don’t need a separate content calendar for every channel. I need one coherent body of work that can support different kinds of explanation.

The factual claim should survive every adaptation. If the experiment covers one controlled setup, the headline cannot turn it into a verdict on all agent systems. If a caveat changes the conclusion, shortening the post cannot erase it.

Automate preparation, keep editorial judgment

The first version of this system can be a coding agent, a folder of research notes, a small idea backlog, and a review checklist.

It can help discover relevant primary sources, propose experiments, organize results, and draft explanations. It can turn a verified finding into a carousel outline or identify places where the prose promises more than the evidence supports. Reproducible benchmarks can run automatically within a defined environment and resource budget.

Before anything is published, I want to check:

  • Can I explain and defend the central claim?
  • Does the evidence support the wording, including the headline?
  • Are methodology, attribution, uncertainty, and important limitations available?
  • Is the material appropriate to share, and does it sound like me?

A draft passing an automated check is still a draft. Scheduling comes after approval of the actual content and destination. Editing a claim afterward means reviewing it again.

Engagement needs the same care. An assistant can collect relevant discussions and prepare a brief. I should decide where I have something to contribute and write or approve the response myself. Automated comments and bulk messages would put words into relationships I am responsible for.

Measure whether the work helps the right people

Reach tells me whether something was seen. It cannot tell me on its own whether the work built technical trust.

I want to record the responses that reveal understanding: someone reproducing an experiment, raising a specific objection, using an artifact, or asking a question that exposes a gap. Professional outcomes matter too, including relevant conversations, collaboration, speaking invitations, and career opportunities.

A lightweight log is enough initially. For each investigation, record the question, intended audience, artifact, formats used, time spent, observed response, and next decision. Missing metrics should stay missing rather than become guessed numbers.

Format experiments need restraint. If I change the topic, hook, visual style, and publishing time together, a better response will not tell me which change mattered. Comparisons across a handful of posts will also be noisy. They can guide the next test without becoming universal rules.

I also want to account for the hours spent. A system that increases output while consuming all the time available for engineering has failed its purpose.

Begin with one complete investigation

The starting cadence in this playbook is two substantial posts a week, with an optional lighter post. I will treat that as a capacity hypothesis. If producing defensible evidence takes longer, the schedule should move.

The first implementation should support one complete cycle: choose a question, investigate it, preserve the evidence, build an artifact, draft the explanation, review it, and publish. Then record what people found useful or confusing.

Only after that cycle works do I want to add more scheduling, analytics, or orchestration. A neglected draft folder is already enough infrastructure to maintain.

The next thing to build is a flagship investigation with a result another engineer can inspect. Its questions and rough edges should determine what the automation layer needs to do.