Future

The Real Token Economy Is Not About Spending Less. It Is About Thinking Smaller.

marcosomma — Sun, 26 Apr 2026 22:46:01 +0000

I saw a video today that made me laugh, then made me a bit worried.

It was one of those jokes that is not really a joke because you can already see some company doing it six months from now. A manager was basically complaining because an employee was not spending enough AI tokens. Not enough tokens. As if tokens were steps on a fitness tracker.

"You only burned 2,000 tokens today, Susan. Are you even working?"

It sounds absurd, but we are not that far from it. Companies are already starting to measure AI adoption through number of prompts, number of tool calls, input tokens, output tokens, cost per user, cost per team, cost per workflow. And to be clear, I do not think this is automatically wrong. Measuring token usage makes sense. Tokens are cost. Tokens are latency. Tokens are context. They are also a trace of how people and systems are using AI.

The problem starts when we confuse the metric with the objective. We did this with hours worked. We did this with tickets closed. We did this with meetings attended. We did this with leads, where 1,000 unqualified leads looked better than 10 serious conversations because the spreadsheet was having a great day and nobody wanted to ruin the mood with reality.

Now we risk doing the same with tokens.

More tokens does not mean better work. Fewer tokens does not mean smarter work. The interesting signal is not the raw number. The interesting signal is the relationship between what you put into the model, what you ask it to do, and what comes out. That is where I think the real token economy starts. Not as a cost saving obsession, but as an architectural signal.

Tokens are not just money

The first way people talk about tokens is cost, and that is understandable. If you use hosted LLM APIs, tokens map quite directly to money. Input tokens cost something. Output tokens cost something. Larger models cost more. Long contexts cost more. Retries cost more. Bad prompts cost more. Bad architecture costs a lot more, but usually in a way that arrives later and looks like a reliability problem.

So the first instinct is to optimize token consumption. Compress prompts. Summarize context. Pick cheaper models. Cache responses. Reduce unnecessary output. All of that is useful, but I think it is only the shallow layer of the problem.

The more interesting question is not "how many tokens did this task consume?" The more interesting question is "what cognitive operation did those tokens represent?"

Because input tokens and output tokens are not the same thing. Input tokens usually buy context. They are the material you ask the model to look at. Output tokens usually buy generation, explanation, structure, synthesis, or action. If I send 10,000 input tokens to a model and get back 10 output tokens, that could be terrible. It could also be exactly right.

If the task is to read a long error log and return whether the failure is caused by authentication, a tiny output may be valid. If the task is to classify a product review as positive, neutral, or negative, a small answer is not a failure. It is the point. If the task is to route a bug report to the correct engineering queue, I do not need a novel. I need the right route.

So no, high input and low output is not automatically bad. But it is a signal. And I think that signal deserves a lot more attention than it currently gets.

Balance does not mean symmetry

When I talk about token balance, I do not mean that input tokens and output tokens should be equal. That would be a very silly metric, and we already have enough silly metrics trying to cosplay as management science.

By balance, I mean the relationship between the size of the input, the size of the output, and the value of the decision produced. A large input with a tiny output usually means the model is doing some kind of compression, classification, extraction, routing, filtering, moderation, scoring, validation, or decision making. A small input with a large output usually means the model is doing generation, expansion, explanation, drafting, or ideation. A large input with a large output usually means synthesis, transformation, summarization, comparison, or multi-step reasoning. A small input with a small output is usually a narrow atomic task.

None of these patterns are good or bad by themselves. They tell you something about the shape of the work. And sometimes the shape of the work is screaming.

Imagine you send a giant prompt containing a full meeting transcript, a product description, usage logs, a bug report, five examples, a JSON schema, tone guidelines, safety instructions, and a final line saying "be concise" because apparently we enjoy irony. Then you ask the model to return this:

{
  "priority": "high"
}

Maybe that is fine. Maybe the classification really required all of that context. But maybe you just built a cognitive washing machine to clean one spoon.

The point is not that the token ratio is wrong. The point is that the ratio invites questions. Did the task need all of that context? Could the context have been retrieved more narrowly? Could the classification have been separated from the extraction? Could a smaller model do part of the work? Could a deterministic rule do part of it? Could the final output be validated separately instead of trusting one giant model call?

That is where token metrics become useful. Not as a scoreboard. As a diagnostic tool.

The real problem is overloaded cognition

A lot of AI workflows are not expensive because the model is expensive. They are expensive because the task design is confused. We ask one model call to do too many things at once, then we act surprised when the model behaves like a very intelligent intern who received eight contradictory Jira tickets in one message.

Read this long input. Understand the domain. Extract twenty fields. Normalize them. Infer missing values. Respect the schema. Apply business rules. Avoid hallucinations. Explain your decision. Be concise. Be deterministic. Also, please do it in one call because we saw a demo once and now we think architecture is a prompt template.

This is where things become fragile. One big prompt. One big model. One fragile JSON output. One retry loop when it fails. One annoyed engineer staring at a malformed comma at 1:12 AM wondering why they studied data structures.

The problem is not only cost. The problem is that the reasoning surface is too large. Every additional instruction increases the model's degrees of freedom. Every unrelated piece of context adds noise. Every extra output field increases the chance of format drift. Every hidden dependency between fields makes validation harder. And when the output fails, you often do not know why.

Was the context too long? Was the instruction ambiguous? Was the schema too complex? Was the task logically overloaded? Was the model too weak? Was the model too creative? Was Mercury in retrograde? At some point, debugging a giant prompt starts to feel like debugging a dream.

This is why I think the unit of optimization should not be the prompt. The unit of optimization should be the cognitive task.

Think smaller, not just cheaper

When people hear "token economy", they often think about saving money. I think that is incomplete. The better version is this: design AI workflows so each model call has the smallest reasonable cognitive surface.

Not the smallest prompt. Not the cheapest model. The smallest cognitive surface.

A task has a cognitive surface when it asks the model to consider a certain amount of context, make a certain type of judgment, and produce a certain kind of output. A wide cognitive surface is something like this: read a conversation, infer the user's emotional state, detect all action items, classify the sales opportunity, extract objections, score urgency, summarize the call, generate a follow-up email, and return a perfect JSON object with 28 fields.

That is not one task. That is a small village.

A narrower cognitive task is different. Given this segment of a product feedback thread, identify whether the user mentions pricing as a blocker. Return true or false. Or extract only the next meeting date from this text and return null if absent. Or given these three already extracted signals, choose the priority level from low, medium, or high.

Those tasks have narrower inputs and narrower outputs. They are easier to validate. They are easier to retry. They can often run on smaller models. Some can be replaced by deterministic code. Most importantly, they reduce ambiguity.

This is the part that matters. The best token optimization is not always compression. Sometimes the best token optimization is decomposition.

The 20 field JSON problem

Let us take a simple example. You have a large input document and you need a structured output with 20 values. The obvious modern AI approach is to send the full document to a model and ask it to extract everything in one JSON object. Add a schema, add "do not hallucinate", add "use null when unknown", maybe add three examples, and hope the model behaves.

Sometimes this works. Sometimes it works very well in the demo. Then production arrives, wearing boots.

The model misses a field. It invents a value. It mixes two fields. It returns invalid JSON. It follows the schema but puts the wrong value in the right place, which is worse because it looks correct. It explains itself inside a field because apparently JSON needed feelings.

So you add more instructions. Then stricter schema language. Then validation. Then retry. Then a stronger model. Then a more expensive model. Then someone says, "Maybe we should fine-tune it." And now your simple extraction pipeline has become a small national infrastructure project.

A different approach is to ask a boring but useful question: are these 20 values actually one cognitive task?

Maybe not. Maybe five fields are direct extraction. Maybe three require classification. Maybe four depend on dates. Maybe two require numerical normalization. Maybe six are only relevant if a previous condition is true. In that case, one big prompt is not simpler. It is only hiding the complexity inside the model call.

You may get a better system by clustering the fields by semantic dependency. For example, direct identifiers can be one batch. Dates and temporal constraints can be another. Risk indicators can be another. Obligations and responsible parties can be another. The final normalized summary can be built only after the previous signals exist.

Each batch can have a smaller prompt, a smaller schema, and a narrower validation rule. Some batches may not need an LLM. Some can use regex, parsers, lookup tables, embeddings, or deterministic checks. Some can use a small local model. Only the genuinely difficult parts need the expensive model.

This is where the cost savings come from, but cost is only one part of the win. You also get better observability. If the final output is wrong, you can inspect which subtask failed. You can measure field-level accuracy. You can retry only the failing part. You can swap models for one stage without touching the rest. You can cache intermediate outputs. You can add deterministic validation at the boundary.

That is a real token economy. Not "use fewer tokens". Spend tokens where cognition is actually needed.

Smaller prompts reduce variance

I want to be careful with the word deterministic. LLMs are not truly deterministic systems in the classical engineering sense, even when you reduce temperature and constrain output. They are probabilistic systems. But workflow design can make their behavior more stable, more reproducible, and more controllable.

Smaller prompts with narrower objectives usually reduce the degrees of freedom of the model. If the model has one job, a small output space, and a strict schema, there are fewer ways to fail. If the model has twenty jobs, a large input, competing instructions, implicit dependencies, and a complex schema, you should not be surprised when it occasionally decides to express itself like a haunted spreadsheet.

This is why task decomposition can improve consistency. Not because small calls magically make the model deterministic, but because small calls make the system around the model easier to control. The output space is narrower. The validation is simpler. The retry logic is cheaper. The failure modes are easier to classify. The model choice becomes more flexible. The prompts become easier to test.

And the orchestration becomes explicit.

That last point matters a lot. When everything happens inside one prompt, the process is invisible. When you split the work into stages, the process becomes inspectable. This is the difference between hoping the model thinks correctly and designing a system where each step can be observed.

Where OrKa fits into this

This is one of the reasons I have been building OrKa, an orchestration framework for AI agents and reasoning workflows. The point of OrKa is not "use more agents because agents are cool". Honestly, if adding agents makes your system less understandable, congratulations, you have invented distributed confusion.

The point is different. Make cognitive work explicit. Define the flow. Split reasoning into smaller units. Route tasks. Log execution. Validate outputs. Keep memory and context under control. Make the system inspectable instead of praying over a large prompt.

In this view, an LLM is not the application. It is one component inside a system. Sometimes the LLM extracts. Sometimes it classifies. Sometimes it rewrites. Sometimes it evaluates. Sometimes it should not be called at all. The orchestration layer decides how work moves between these pieces.

That is where token economy becomes architecture. You are no longer asking only how to reduce a prompt by 20 percent. You are asking which cognitive step actually needs this context.

That question changes everything. Maybe the first model call only needs the user message. Maybe the second needs the relevant log snippet. Maybe the third needs only three extracted fields. Maybe the final formatter needs no model at all. If you send the full context to every step, you are not designing an AI system. You are photocopying the universe and asking a model to find the invoice number.

It may work. It is not a strategy.

Token metrics should trigger questions

So how should teams use token metrics? Not as productivity surveillance. Not as a way to shame people for using too many or too few tokens. Not as a leaderboard where the person with the most prompts wins some cursed office trophy.

Token metrics should trigger engineering questions.

When input tokens are very high and output tokens are very low, ask whether the task is intentionally compressive or accidentally overloaded. When output tokens are very high, ask whether the model is generating useful structure or just producing expensive fog. When the same context is repeatedly sent across multiple calls, ask whether retrieval, caching, or state passing could reduce duplication. When a large model is used for simple extraction, ask whether a smaller model or deterministic rule would work. When retries consume a lot of tokens, ask whether the schema, validation, or task boundaries are wrong.

This does not mean splitting tasks is automatically better. If you send the same 10,000 token input twenty times to extract twenty fields, you may have made the system more expensive and slower. You have not built architecture. You have built a very complicated way to duplicate context.

The win comes when decomposition is paired with context narrowing. Extract the relevant segment once. Reuse intermediate state. Cluster fields that share dependencies. Route only the necessary context. Validate locally. Use smaller models where possible. Stop calling the model when code can do the job.

This is not anti-LLM. It is pro-system.

A simple mental model

Here is the mental model I keep coming back to. Input tokens are attention budget. Output tokens are commitment surface.

The more input you provide, the more the model has to attend to. The more output you request, the more opportunities the model has to drift. A workflow becomes more stable when the attention budget and the commitment surface are aligned with the actual cognitive task.

If the model needs to classify one thing, do not ask it to also summarize, extract, explain, normalize, and format a complex object. If the model needs to generate a long answer, do not overload it with irrelevant context that only increases noise. If the model needs to extract structured fields, do not assume all fields belong in the same call. If the model needs to make a decision, make the decision boundary explicit.

The goal is not minimal tokens. The goal is minimal unnecessary cognition.

That distinction is important. Some tasks deserve many tokens. A long research synthesis may need a lot of context. A technical incident summary may need careful source retention. A product comparison may need long input and long output. A multi-document comparison may be legitimately expensive.

The problem is not spending tokens. The problem is spending tokens without knowing what they are buying.

This is also a model selection problem

Once you split cognitive tasks, model selection becomes much more interesting. In a one-prompt architecture, you usually choose the strongest model you can afford because the task is messy. The model has to handle everything. It has to read long context, reason, extract, format, validate, and recover from ambiguity.

But if you split the workflow, you can choose models per cognitive step. A small model can do simple classification. A local model can extract obvious fields. A deterministic parser can normalize dates. A rules engine can validate constraints. A stronger model can handle the genuinely ambiguous reasoning.

This is where the economics change. Not because you begged the prompt to be shorter, but because you changed the shape of the work. The expensive model becomes a specialist instead of a landfill.

And yes, I know "landfill" sounds harsh. But many AI systems today are exactly that. They throw all context into one place and hope the biggest model will recycle it into something useful. This works surprisingly often, which is the dangerous part. It works enough to ship a demo. It fails enough to punish you in production.

Token economy as observability

A mature AI system should not only log the final response. It should log the token shape of the workflow.

Which step consumed the most input? Which step produced the most output? Which step retried the most? Which step had the most schema failures? Which step required the strongest model? Which step could be cached? Which step could be replaced by code? Which step actually improved the final decision?

This is not accounting. This is observability.

You are not only tracking spend. You are tracking cognitive pressure inside the system. A sudden increase in input tokens may mean your retrieval is bringing too much context. A sudden increase in output tokens may mean the model started explaining instead of structuring. A high retry cost may mean your schema is too complex or your prompt is ambiguous. A high token cost on a low-value decision may mean the workflow needs decomposition. A low token cost with poor quality may mean you compressed away necessary context.

Again, the metric is not the answer. The metric is the signal. The engineer still needs judgment, which is very inconvenient. We were promised automation and somehow we still need thinking. Rude.

The wrong future

The wrong future is easy to imagine. Teams get AI dashboards. Managers see token usage per employee. People are encouraged to "use AI more". Token consumption becomes proof of adoption. Employees learn to generate more prompts because the dashboard rewards activity. Everyone looks productive, costs go up, and quality does not.

Then leadership announces an AI efficiency initiative. Now everyone must reduce token usage. People use smaller prompts. Quality drops. Nobody knows why. Another dashboard is created. A consultant appears. The circle of life continues.

This is what happens when the metric becomes the goal. Token usage by itself tells you almost nothing about quality. A great engineer may use fewer tokens because they decomposed the problem properly. Another great engineer may use more tokens because the task genuinely required context. A bad workflow may use few tokens and produce garbage. A good workflow may use many tokens and produce a high-value decision.

So measuring tokens is not wrong. Judging work by raw token volume is wrong.

The better future

The better future is more boring, which is usually a good sign in engineering. Teams treat token metrics as workflow diagnostics. They look at input-output patterns. They identify overloaded prompts. They split tasks where it makes sense. They route context more carefully. They use smaller models for smaller cognitive jobs. They validate structured outputs separately. They measure retries, drift, and failure modes.

They do not ask "how much AI did you use?" They ask "where did the AI actually add decision value?"

That is the mindset shift. Tokens are not just a bill. Tokens are a trace of cognitive architecture. They show where a system is bloated. They show where context is duplicated. They show where outputs are too ambitious. They show where models are being used as glue because nobody wanted to design the pipeline. And yes, sometimes they show that the expensive model was actually justified.

That is fine. The goal is not to make everything cheap. The goal is to make the system honest.

Final thought

I think the next stage of AI engineering will not be about who writes the cleverest prompt. It will be about who designs the clearest cognitive pipeline.

The prompt is not the unit of architecture. The cognitive task is.

Token balance matters because it gives us a way to inspect that task. Not perfectly. Not automatically. Not as a KPI to punish or reward people. But as a signal that says: maybe this workflow is overloaded, maybe this context is too broad, maybe this output is trying to do too much, maybe this model is stronger than necessary, maybe this task should be split, maybe this step should not use an LLM at all.

That is where the real token economy lives. Not in spending fewer tokens, but in spending attention where attention is needed.

If we do that well, the benefits go beyond cost. Lower latency. Smaller models. Cleaner validation. Less format drift. More stable outputs. More inspectable workflows. Systems that are closer to engineering and less close to whispering wishes into a very expensive autocomplete machine.

Which, to be fair, is still fun.

But maybe not the future we should build production systems on.

Built a native MCP server for Odoo so Claude, Cursor, and Codex can drive it directly

Mathias Markl — Sun, 26 Apr 2026 22:42:25 +0000

Most Odoo MCP integrations I came across follow the same pattern: a separate Python process running on your machine (or in a Docker container), talking to Odoo over XML-RPC or JSON-RPC from the outside. It works, but you end up with credentials in env files, a second thing to deploy and keep alive, and no real visibility into what the AI did from inside Odoo.

I wanted something different, so I built muk_mcp — an open-source addon (LGPL-3) that makes Odoo itself the MCP server. No extra process, no middleware, no RPC bridge. The /mcp endpoint lives inside the registry and runs through the same ORM as everything else.

Install it, generate an MCP key from your user preferences, paste the URL into Claude Code, Claude Desktop, Cursor, Windsurf, Codex CLI, or OpenCode. The model gets 15 typed tools covering the full ORM lifecycle — model discovery, schema introspection, search, read, create, update, delete, grouped aggregation, chatter, and method execution.

Per-key scopes, rate limits, and audit log

Each key supports model-level scopes with separate read / write / create / delete permissions. Configurable rate limit per key (default 60 req/min). Every call lands in an audit log with method, tool, model, duration, and status.

Custom tools without leaving the UI

Custom tools can be added directly from the backend UI — name, description, JSON Schema for inputs, and Python in a sandboxed safe_eval context. No code deployment, no server restart. The connected client gets notified when the tool list changes.

Sessions are stateful per the MCP spec and clean themselves up after the configured timeout. Users can revoke their own sessions from preferences.

MCP-tagged chatter

Every chatter message authored by an MCP tool is tagged with a small MCP badge next to the author name, so it is immediately obvious which comments, status changes, and tracking entries came from an AI client and which came from a human.

The Bug That Cost Me Three Weeks: Why Your SL/TP Logic Is Probably Wrong

Vuk Stanic — Sun, 26 Apr 2026 22:36:41 +0000

This is the story of a production bug I fixed, turned into a book. It's also why most algorithmic traders fail.

Every algorithmic trader thinks they understand stop-loss and take-profit (SL/TP). Most are wrong. Not subtly wrong — catastrophically wrong in ways that don't show up in backtesting but destroy live systems.

This is the opening chapter of my second book, and it's the reason I wrote the whole series.

The Naive Implementation

Here's what the original code looked like in our production system:

struct Position {
    entry_price: Decimal,
    sl_price: Decimal,
    tp_price: Decimal,
    sl_triggered: bool,
    tp_triggered: bool,
}

fn check_sl_tp(position: &mut Position, current_price: Decimal) {
    if current_price <= position.sl_price && !position.sl_triggered {
        position.sl_triggered = true;
        close_position(position);
    }

    if current_price >= position.tp_price && !position.tp_triggered {
        position.tp_triggered = true;
        close_position(position);
    }
}

Looks reasonable, right? Check price against SL/TP levels, set a flag, close if triggered.

It failed in production. Here's why.

Failure Mode 1: Flag-Based Checking Doesn't Track What Actually Happened

The problem with sl_triggered: bool is that it tells you that something happened, but not what actually happened.

Consider this sequence in a fast-moving market:

T=0:    Price at $105.00, position long with SL at $100.00
T=1:    Price drops to $99.95 (below SL!)
T=2:    Your check runs, sets sl_triggered = true
T=3:    Your system submits close order at $99.95
T=4:    Price bounces back to $100.50
T=5:    Exchange confirms: fill at $99.95

Your code set sl_triggered = true when price crossed $100.00. The exchange filled you at $99.95. Your flag doesn't tell you what fill price you actually got.

More critically: In step T=4, before the exchange confirmed the fill, your code thought "SL triggered, position closed." But the position wasn't actually closed yet — it was in flight.

This is the state vs event confusion. Your flag tracks an event (trigger), not a state (position actually closed).

Failure Mode 2: Re-Entry on the Next Tick

Here's where it gets really bad. After the SL triggers:

T=10:   Price moves back up to $102.00
T=11:   Your strategy sees "price is $102, no open position"
T=12:   Strategy decides to re-enter long
T=13:   New position opened at $102.00
T=14:   Price drops again to $99.90
T=15:   Another SL triggered, another loss

Your system has no memory that the previous close was an SL close. It just sees "no position, price looks good, buy."

This is the re-entry problem — and it's more expensive than the original loss.

The Correct Mental Model

SL/TP should be state-based, not event-based. Instead of "did we trigger?" think "what should we do given the current state and price?"

enum PositionState {
    Open,           // Position is active, checks are running
    ClosePending,   // Close order submitted, waiting for fill
    Closed,         // Position fully exited, no more checks
}

struct Position {
    entry_price: Decimal,
    sl_price: Decimal,
    tp_price: Decimal,
    state: PositionState,

    // Track the close order, not just the trigger
    close_order_id: Option<u64>,
    close_trigger_price: Option<Decimal>,
    opened_at_ns: u64,
    close_submitted_at_ns: Option<u64>,
    closed_at_ns: Option<u64>,
}

Key difference: The close_order_id field tracks the actual close order, not just a trigger flag. If you have a close order ID, the position is in ClosePending state. If it's filled, the state transitions to Closed.

enum SLTPAction {
    Nothing,
    TriggerSL,
    TriggerTP,
}

fn check_sl_tp(position: &Position, current_price: Decimal) -> SLTPAction {
    if position.state != PositionState::Open {
        return SLTPAction::Nothing;
    }

    if current_price <= position.sl_price {
        SLTPAction::TriggerSL
    } else if current_price >= position.tp_price {
        SLTPAction::TriggerTP
    } else {
        SLTPAction::Nothing
    }
}

fn on_action(position: &mut Position, action: SLTPAction, current_price: Decimal) -> Result<(), Error> {
    match action {
        SLTPAction::Nothing => Ok(()),
        SLTPAction::TriggerSL | SLTPAction::TriggerTP => {
            let order_id = submit_close_order(position, current_price)?;
            position.state = PositionState::ClosePending;
            position.close_order_id = Some(order_id);
            position.close_trigger_price = Some(current_price);
            position.close_submitted_at_ns = Some(current_timestamp_ns());
            Ok(())
        }
    }
}

Why Backtesting Misses This

In backtesting, prices are usually bar-based (OHLC). The SL/TP check happens once per bar at the close. In live trading, you're checking every tick. A tick-based system might check SL/TP 100 times per second.

The bug manifests in live trading because:

Price crosses SL
Your check runs, returns TriggerSL
You submit close order
Meanwhile, price bounces back above SL
Your check runs again, sees price above SL, does nothing
But your close order is still pending...

The flag-based approach doesn't know that a close order is already in flight. It sees price above SL and would try to trade again.

The Actual Production Failure

Our original system had this flow:

1. Position opened at $100.00, SL = $98.00, TP = $102.00
2. Price drops to $97.50
3. check_sl_tp() sets sl_triggered = true
4. close_position() called
5. Position state set to "closing" (but not "closed")
6. Order submitted to exchange
7. Network latency = 50ms
8. Price bounces back to $99.00
9. check_sl_tp() runs again — price above SL, does nothing
10. Strategy continues to next tick
11. Exchange confirms fill at $97.50
12. Position is now closed

All good so far. But then:

13. Next tick arrives
14. Strategy sees: "no open position, price is $99, this looks like a buy"
15. New position opened at $99.00
16. Price drops again to $97.50
17. Another SL triggered

The problem: Steps 13-15 happened while the close order was still in flight. The strategy saw "no position" because the position was in "closing" state but hadn't confirmed "closed" yet.

We fixed this by adding close order tracking — the system now knows that a close is pending and doesn't allow new positions until the close is confirmed.

What I Learned

Two things:

1. State machines over flags. Every position should follow a clear state machine: Open → ClosePending → Closed. Transitions happen on confirmed events, not on trigger signals.

2. Backtesting lies to you. The bug never appeared in backtesting because we checked once per bar. In live trading, the race condition happens between ticks. Your backtest looks perfect. Your live account doesn't.

This is Chapter 1 of "The Circuit Breaker Problem" — one of five books in the Trading System Engineering Bundle. All written by an engineer who actually built a production trading engine from scratch. Code templates included.

What's in the bundle:

Order Engine Architecture — FIFO matching, order book data structures
The Circuit Breaker Problem — SL/TP bugs, trailing stops, re-entry prevention
Data Pipeline — TVC3 binary format, ring buffers, VPIN
Risk Management Engineering — commission handling, Kelly criterion, drawdown
Backtest Architecture — look-ahead bias, slippage modeling, walk-forward analysis

$20 per book, $80 for the bundle. Free preview: Book 2, Chapter 1.

on the plane, again

Philip Hern — Sun, 26 Apr 2026 22:35:23 +0000

thesis

my opinion on using wifi on a plane has shifted. i do not think it is the right default for everyone in every situation, but when i am traveling alone, especially for work, i have started to treat a connected cabin as a feature. it takes hours that used to feel like pure waiting, time i was just trying to burn through, and turns them into a stretch where i can work with a surprisingly solid level of focus and relatively few distractions.

context

a few weeks ago i wrote about how torn i still was on this topic in plane wifi: when the cabin forced disconnect. that piece was an honest inventory of the tradeoffs. this one is an update from the other side of the choice, after i have spent more flights actually buying the pass and sitting down to work instead of debating it.

argument

when i am alone and the trip is for my job, the row stops feeling like a cage and starts feeling like a quiet room with bad legroom. i already have headphones in, so the cabin noise is under control. notifications are fewer than at my desk, nobody is making noise by my office door, and the margin of "things i could be doing instead" feels narrower. it is not peace and it is not deep rest, but it is a usable kind of concentration.

i am now using that block to write, to debug, to plan, and to close loops i would otherwise push to after i land. i go in knowing i will get a meaningful amount done, and that expectation makes the clock feel less stuck. the time still passes at the same speed, but it passes with output attached, and that changes how it feels in my body.

i also have a concrete proof point that this mode is not just talk. i completely stood up my personal website while airborne, end to end, in one of those sessions. right now i am on a plane again, getting ahead for an in-person meeting so i can walk in prepared instead of scrambling on the jet bridge.

tension or counterpoint

i am not arguing that every person should pay for wifi on every flight. shared trips, family logistics, the middle seat, motion sickness, or the simple need to be offline are all good reasons to skip it. economy is still a bad default office for anyone who needs space or quiet that the cabin cannot give. my point is narrower. for me, in the situations where it fits, the cost of the pass is cheaper than the opportunity cost of treating the whole flight as lost time.

closing

i will probably still sometimes want the cabin to be an excuse to be unreachable. when i do, i can leave the wifi off. when i do not, i am glad the option exists, and i am using it on purpose.

related on this site

logic

Philip Hern — Sun, 26 Apr 2026 22:35:21 +0000

thesis

learning basic logic is one of the most useful, durable skills i can recommend to anyone, regardless of profession. the english-language version of if/then/else is a thinking tool that works everywhere, never expires, and quietly compounds into better decisions over a lifetime.

context

most people associate logic with code, math, or a philosophy classroom. that framing is too narrow. logic is just structured cause-and-effect thinking, and the simplest version of it sounds exactly like english:

if this, then that, else that other thing

once you can hold that pattern in your head on purpose, it changes how you plan, diagnose, design, and interpret almost everything in front of you. you do not need a programming language to use it. you just need to be willing to slow down for a beat and think in branches instead of straight lines.

a few familiar gates

here a few small pictures to demonstrate simple examples of logic gates that you already use in daily life. this just illustrates it so you can literally follow along with the logic gates as each situation progresses.

and both must be true for the outcome to be true
or at least one true is enough
not you follow the opposite branch of the test

the flow is the same kind of small chart you would sketch on a napkin.

{{< mermaid >}}
flowchart TB
subgraph g_and [and, both need to be true]
direction LR
w[good weather?] --> and1{and}
f[afternoon free?] --> and1
and1 -->|yes| hike[go hiking]
and1 -->|no| home[stay in]
end
subgraph g_or [or, at least one is enough]
direction LR
car[friend can drive?] --> or1{or}
bus[transit is running?] --> or1
or1 -->|yes| go[you can get there]
or1 -->|no| stuck[you are stuck]
end
subgraph g_not [not, the opposite branch of the test]
direction LR
pow[power on?] -->|no| br[check the breaker]
pow -->|yes| next1[next check in the chain]
end
{{< /mermaid >}}

none of that requires a keyboard. it is the same branch habit as the if/then/else line in the last section, just drawn with a few boxes.

argument

logic is a thinking tool, not a coding tool

the if/then/else pattern is older than any programming language. when i write a small script, i am formalizing the same branching i already do when i pick what to wear, route around traffic, or decide how to respond when something at work breaks. the keyboard is incidental, the structure is the point.

this kind of structured thinking is what moves me from "i feel stuck" to "what is the next decision, and what are the branches under it". that small shift, from a vague feeling to a concrete branch point, is where most of the leverage comes from.

where it pays off in normal life

once you start noticing branches, you see them everywhere. planning a day with kids becomes a small logic tree. if the weather holds, we hike. if it does not, we move to the indoor option. if both fail, we cancel and reschedule. naming the branches up front means the day does not collapse when conditions change.

troubleshooting has the same shape. when something is not working, i walk a tree out loud. if the appliance has power, then check the next link. if not, then check the breaker. each step rules out a branch and shrinks the search space.

designing a process at work has the same bones. i list the conditions first, then the path each one takes. naming the branches early makes the design easier to explain and easier to fix later.

understanding behavior is harder, but the structure still helps. people are not perfectly logical, but their patterns often are. if my kid is tired, then certain tantrums become more likely. if a colleague is overloaded, then certain reactions track. recognizing the antecedent makes the response less personal and easier to handle.

reverse engineering is the same thing run backward. when i look at a result and want to understand how it got there, i walk the logic in reverse. if this output exists, then these inputs and conditions must have been true. if not, then the model i had in my head is wrong, and that gap is useful information on its own.

the tool never goes out of style

frameworks change. tools change. programming languages come and go. if/then/else does not. it is a structure of thought, not a piece of technology, which is why it keeps working in domains it was never designed for. cooking, parenting, negotiations, medical decision trees, customer support scripts, and legal arguments all lean on the same scaffolding.

i find real comfort in skills that age well. so much of what i learn in tech has a short half-life now. logic does not. once i have it, i have it for good.

applying it broadly is what makes it powerful

a tool that works in one place is useful. a tool that works everywhere is leverage. logic works everywhere because every domain has cause and effect, conditions, and outcomes. that generality is the multiplier, and it is the same kind of cross-domain value i wrote about with adaptability. the principle stays steady while the surface details swap.

learn it as early as you can

the earlier this gets internalized, the more downstream decisions inherit it. a kid who can think in branches asks better questions, accepts fewer "because i said so" answers, and gradually builds a habit of checking conditions before reacting. that habit then runs in the background for the rest of their life.

i think about this with my own kids, and i think about it for myself. every year i wait to make decisions more deliberately is a year of slightly noisier decisions stacked behind me.

the butterfly effect of better decisions

small improvements in single decisions do not look like much in isolation. two paths that differ by one degree at the start can end up far apart over a long enough timeline. better daily decisions, even by a thin margin, compound the same way a little becomes a lot does for habits. the quality of the inputs, repeated across years, becomes the quality of the life.

logic is one of the cheapest ways i know to nudge that compounding in a good direction.

tension or counterpoint

logic on its own is not the whole answer. real situations carry emotion, ambiguity, missing information, and people who do not behave according to clean rules. if i treat every interaction like a flowchart, i lose intuition, empathy, and the ability to sit with uncertainty.

the skill is to use logic as scaffolding, not as a replacement for judgment. i map the branches i can see, then i listen for the part that the branches do not capture. both layers matter, and the logical part actually helps the intuitive part by giving it a clean place to stand.

closing

this is one of the cheapest, most durable investments anyone can make. learn the english-language form of if/then/else. practice naming the conditions and the branches in your own life. apply it to planning, troubleshooting, designing, and understanding the people around you.

learn it once and you keep it forever. apply it everywhere and it compounds. not many skills pay back like that.

related on this site

My Wallet Experiences

Hope — Sun, 26 Apr 2026 22:29:11 +0000

What I did: This week, I went from generating raw key pairs in the terminal to building a web app that connects to browser wallets like Phantom.

What surprised me: The biggest "aha" moment was realizing that a wallet is a UI for a cryptographic key pair that serves as my universal identity.

What's next: I'm excited to move past the basics and start writing my own on-chain programs!

I Saved 2 Hours a Week by Automating My Changelog — Here's Exactly How

shiplog-bot — Sun, 26 Apr 2026 22:21:02 +0000

Last Tuesday, I spent 45 minutes staring at a spreadsheet of commit messages trying to turn "fix: prevent undefined refs in memo" into something a human would actually want to read.

That was the moment I realized I'd been doing changelog work wrong for three years.

I'm not talking about minor annoyance—I'm talking about the slow bleed of context-switching that kills momentum. Every Friday, I'd context-switch from shipping features into "changelog mode," where I'd hunt through 30-50 commits, decode abbreviations, figure out what actually mattered to users vs. what was internal scaffolding, and then rewrite everything in three different voices so different stakeholders could understand it.

Two hours. Every. Single. Week.

That's roughly 100 hours a year I wasn't building, debugging, or thinking clearly.

So I built something to fix it: Proseflow.

It's an AI changelog generator that pulls your GitHub commits, understands context through OpenAI's GPT-4o-mini, and spits out a polished changelog in three tones: developer-focused, user-friendly, and executive summary. I'm open-sourcing my process here because if you ship software and maintain a changelog, this probably applies to you too.

The Problem (Before)

Here's what my typical Friday looked like:

Open GitHub, filter commits from the past week
Copy-paste into a markdown file
Rewrite 60% of them because "chore: update deps" doesn't tell users anything
Split into three separate sections (for devs, for users, for leadership)
Proofread, add links, cross-check with PR titles
Repeat next week

The context-switch tax was brutal. By the time I finished, I'd lost the thread on the feature I was actually building.

The Solution (After)

I built Proseflow to do this in one click.

Real Example: Before → After

Here's what actually happened last week with a real commit batch:

Raw commits:

fix: resolve race condition in useAuth hook
feat: add webhook retry logic with exponential backoff
chore: bump @openai/sdk to 4.52.0
fix: sanitize user input in form validator
perf: memoize expensive cart calculations
docs: update API reference for batch endpoints

Proseflow output (3 versions):

Developer Tone:

## v1.2.4 - Jan 15, 2025

### Features
- **Webhook Retry System**: Implemented exponential backoff for failed 
  webhook deliveries. Reduces manual retry overhead and improves reliability 
  for payment integrations.

### Fixes
- Fixed race condition in `useAuth` hook that could cause stale token 
  references in concurrent renders
- Sanitized form validator inputs to prevent XSS vulnerabilities

### Performance
- Memoized cart total calculations (expensive deep-object comparisons now 
  cached per session)

### Dependencies
- Updated `@openai/sdk` to 4.52.0

User-Friendly Tone:

## What's New in v1.2.4

We've made your experience more reliable and faster:

- **Payments are now more reliable**: If a payment notification fails, 
  we automatically retry it. No more missing transactions.
- **Faster checkout**: Your cart now loads noticeably faster, 
  especially with lots of items
- **Improved security**: We fixed some edge cases in our form handling 
  that could have exposed user data (already patched in production)

Executive Tone:

## v1.2.4 Release Summary

**Impact**: Improved system reliability and user experience
- Webhook retry logic reduces failed payment notifications by ~15%
- 40% faster cart rendering on high-volume carts
- Security hardening in form validation (no user impact; proactive fix)

Time to generate all three: 8 seconds.

Time I previously spent: 45 minutes.

How It Actually Works

Proseflow is built on three core pieces:

1. GitHub OAuth (via NextAuth)

When you connect Proseflow, it asks for read-only access to your repositories. It never commits, pushes, or modifies anything—just reads commit history.

2. Commit Intelligence (GPT-4o-mini)

I'm using OpenAI's GPT-4o-mini (not the full GPT-4o—cost matters) to:

Parse commit messages and extract intent
Identify breaking changes automatically
Group related commits into features/fixes/chores
Generate three independent versions

The prompt engineering was the hard part. The model needs context about what actually matters—a security fix matters differently than a dependency bump.

3. One-Click Export

The changelog renders as markdown you can copy, edit, and publish. No vendor lock-in.

The Technical Stack

Frontend: Next.js 14 (App Router)
Auth: NextAuth.js (GitHub OAuth)
AI: OpenAI GPT-4o-mini
Deployment: Vercel
Styling: Tailwind CSS

Real Time Savings

Task	Before	After	Weekly Savings
Commit parsing	15 min	0 min	15 min
Tone rewriting (3x)	20 min	0 min	20 min
Proofing/editing	10 min	3 min	7 min
Total	45 min	3 min	42 min/week

42 minutes × 52 weeks = 36 hours per year back in your pocket.

Being Honest About What This Is

Proseflow is currently free during beta. That won't last forever, but right now I'm optimizing for real feedback over revenue.

Is it perfect? No. Sometimes it groups commits weirdly or makes tone choices you'd do differently. But it handles 80% of the grunt work automatically—and that's the meaningful part.

(Full transparency: the core system was built with significant AI assistance, as part of an autonomous agent experiment. The code is real, the GitHub integration is real, and the generated changelogs are real.)

Try It

If you ship software on a regular cadence, spend 2 minutes trying it:

→ proseflow-v1.vercel.app

I'd love feedback—especially if there's a tone that doesn't land or a commit type it consistently misses. Drop a comment below or open an issue on the repo.

Even if it saves you half the time it saves me, that's worth the two-minute setup.

Authenticating AI Agents Without Shared Secrets

Pico — Sun, 26 Apr 2026 22:20:54 +0000

The credentials problem nobody's fixing

Every AI agent framework in 2026 has the same security architecture: environment variables. Your agent gets an API key. That key lives in memory for the entire session. If the agent is compromised, the key is compromised. If the platform hosting your env vars is breached (Vercel disclosed unauthorized access to internal systems in March 2026), every agent using those credentials is exposed.

This isn't hypothetical. An autonomous agent with database access deleted production volumes on Railway earlier this year. The post-mortem blamed the model. The actual failure: the agent had root-level database credentials with no expiry, no scope limitation, and no way to trace which session performed the deletion.

Traditional auth assumes a human is present. OAuth requires browser redirects. API keys are shared secrets that live forever until someone remembers to rotate them. Neither works when the caller is software running unattended across organizational boundaries.

What agents actually need

Three properties, none of which existing auth provides.

The agent must prove who it is without revealing a reusable credential. If you intercept the proof, you can't replay it tomorrow. The token must expire: issued for this session, this task, this hour. And any service receiving a request must verify the identity offline, without calling back to a central registry.

Ed25519 JWT: the boring solution

We issue each agent session a signed JWT using Ed25519 (the same EdDSA curve used in Visa tap-to-pay). The token:

{
  "iss": "https://agentlair.dev",
  "sub": "acc_7kQ2mN",
  "aud": "https://service.example",
  "exp": 1714176000,
  "iat": 1714172400,
  "jti": "aat_xR9f2k",
  "al_scopes": ["email:send", "api:read"],
  "al_audit_url": "https://agentlair.dev/v1/audit/aat_xR9f2k"
}

One hour TTL. Scoped to the specific service the agent calls. Every token gets a unique ID (jti) linked to a full audit trail.

Verification is standard JWKS (RFC 7517). The public key sits at /.well-known/jwks.json. Any HTTP client can fetch it, cache it for an hour, and verify tokens offline from that point. A Go service, a Python function, a Cloudflare Worker all verify the same token the same way. No SDK. No vendor lock-in.

Why Ed25519? 64-byte signatures (half of RSA-2048), deterministic signing (no nonce reuse vulnerability), and the clearest post-quantum migration path. The signing key never leaves the platform. Agents receive tokens; they don't hold signing material.

How agents pay for things

Identity alone doesn't solve the economics. When an autonomous agent needs to send an email or call a paid API, who pays? The traditional answer: the developer's credit card, via an API key. Which loops back to shared secrets.

We use HTTP 402 (Payment Required) with the x402 protocol. When an agent exceeds its free tier, the service returns a 402 with payment terms instead of a 429:

{
  "x402Version": 2,
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "maxAmountRequired": "10000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0x90EE..."
  }]
}

The agent signs an EIP-3009 transferWithAuthorization. A USDC transfer on Base, authorized off-chain. 0.01 USDC per email. No gas estimation, no wallet popup, no human in the loop. Payment settles after the operation succeeds. The agent's economic activity is as auditable as its identity.

What production feedback says

The crewAI RFC on agent identity (#5561) has drawn 12 comments from 7 contributors in six days. BobRenze, who run production multi-agent systems, confirmed they hit the exact OWASP ASI03/ASI07 gap this architecture addresses. Their systems independently converged on the same hybrid: session tokens for identity, per-call tokens for actions.

Microsoft's Agent Governance Toolkit (open-sourced April 2, 1,266 GitHub stars) arrived at Ed25519 DIDs with dynamic trust scoring without coordination. Different scope (single-deployment, not cross-org), but when two independent projects converge on the same cryptographic primitive and trust model, the design space is probably real.

Meanwhile, only 18% of security leaders say their identity systems handle agents (Strata survey, April 2026). The gap between "agents are in production" and "agents have identity" is growing.

What no framework ships

Every agent framework handles tool use, memory, and orchestration. None handle identity. Your agent can query a database, write code, send emails, manage files. It can't prove who it is to the service on the other end of the call.

That's the layer we built. Ed25519 JWTs, JWKS verification, x402 payments, behavioral trust scoring across organizational boundaries. Standard protocols. One-hour token lifetimes.

The spec and implementation: agentlair.dev. The crewAI integration discussion: crewAI #5561.

How Identity Actually Works on Solana

Hope — Sun, 26 Apr 2026 22:14:51 +0000

Beyond Passwords: Understanding Identity on Solana

In the Web2 world, your identity is basically a row in a database owned by someone else. You have a username for GitHub and an email for Google. You rely on these companies to hash your password, handle forgotten password emails, and keep your data safe. On Solana, there are no databases or admins. Your identity is built on the keypair.

Think of it Like an SSH Key

If you’ve ever connected to a server using an SSH key, you already understand Solana. You generate a public key and a private key. You share the public one and keep the private one hidden. To prove who you are, you use the private key to sign a request.

On Solana, the entire network is the server. Your public key is your address, and your private key is your proof of ownership. To move money or talk to a smart contract, you just sign the request with that private key.

Why Addresses Look So Weird

Instead of a username, a Solana address looks like a long string of random characters. This string is encoded in Base58.

Solana uses Base58 to prevent human errors. It removes confusing characters that look alike, such as:

The number zero (0)
The capital letter O
The capital letter I
The lowercase letter l

This makes it much harder to make a mistake when you are copying or reading an address.

You Are the Only Boss

In Web2, a company can lock your account or get hacked. They own your data. You just have permission to use it. On Solana, ownership is cryptographic. Only the person holding the private key can make changes.

There is no password reset button. If you lose your private key, you lose your account forever. While that sounds scary, it also means no company or admin can ever block you or take your funds. You are in total control.

One Key for Everything

Because your identity is based on math, it works everywhere. You just connect your wallet, and every game, marketplace, or exchange on the network instantly knows it's you. It’s like having a universal passport that works across the entire internet without needing anyone's permission.

How to Grow Your Network

Yaroslav Tkachenko — Sun, 26 Apr 2026 22:14:44 +0000

Growing your network is likely one of the most important things you can do before becoming a full-time solopreneur. And yet, many engineers don’t know how to approach it.

Having a large network is important for many reasons. In a services/consulting business, your network (and the references you get from it) becomes the source of your contracts. In a product business, it generates users.

And even if you don’t become a solopreneur, your network can provide better employment opportunities, so growing it is a no-brainer.

What is Network?

But what is it, really? Your network is not the number of followers you have. It’s about people you can reach out to. People who will respond when they hear from you. And, most importantly, people who will help, refer, recommend, try, and offer their time.

So, how do you get people like these?

The Most Important Rule

The rule is simple: you need to be able to provide value. It may sound transactional, but it works.

Agree to provide feedback on a product MVP. Give advice on how to fix a problem. Write a recommendation later. Support someone’s promotion case. Meet with an intern for a coffee. And so on.

You’ll likely not benefit from it. But you’re building relationships , not clients. This is a long game to play.

And always make sure to follow up when you promise something. You want to be remembered as a person who delivers.

Ways to Grow

Your Current Job

This is the most effective way. People really value coworkers they previously enjoyed working with. Of course, you have to be that coworker. Offer help. Offer feedback. Unblock. Support. Be generous with your time.

When I worked at Shopify as a Staff Engineer, I had more 1:1s than my manager. Shopify is a really big organization, and I wanted to engage and collaborate with many brilliant engineers. I had three types of 1:1 meetings:

My teammates. In some companies with heavy processes, you may end up talking to your teammates all the time. Especially if you work in the same location. In other places, especially remote, it’s not always the case. So, make sure you spend enough face-to-face time and genuinely try to be helpful.
My mentees. Shopify had an official mentorship program, but I also unofficially started mentoring more junior engineers. Just because I recognized the potential and wanted to help.
My peers. Staff and Senior Staff engineers who were responsible for other parts of the Data Platform. Some were in different departments. I wanted to stay up-to-date on major initiatives (ideally try to influence them), and offer my help in aligning and unblocking major projects.

Some of these relationships really paid out: when I joined the next company as a Founding Engineer, I built my team exclusively from the folks I previously worked with and mentored.

Also, this might be another reason to switch jobs. I’m not proposing job hopping, but the math is hard to beat: working in 3 places 3-4 years each will generally grow your network much faster than staying in one place for 10 years.

Events

Conferences and meetups are really powerful ways to meet people you’ve never interacted with before. I’m an introvert, but I still find these events really useful. In retrospect, they made a huge impact on my career.

And again, many engineers don’t really know how to properly attend these events if they want to grow their network.

First of all, you’re not there to watch talks. Most conferences nowadays record their talks; they’ll be available for watching later. There are only a few reasons to spend your time on someone's talk:

The content is extremely relevant for you right now, and you can’t wait a few weeks for the recordings to be available.
You want to support the presenter and engage them after the talk.
You’re planning to write a post about the conference :)

So what do you do instead? You go to the “hallway track”: a place where most of the people hang out outside of the talks. Generally, something like an expo hall.

Start talking to people. Introduce yourself, but don’t talk about you all the time! You are there to listen. Ask about people’s challenges. And when you get enough information, offer to help. Offer to try their product. Offer to provide feedback. Offer to go over their problem yourself, or introduce them to someone else who can help. See The Most Important Rule again - be helpful!

If you already offer a service (maybe part-time), you can come much more prepared.

Many fancy conferences these days show attendees in their apps. So, do your homework and analyze them. Find people from relevant companies, write them down. You can even reach out before the event and say something like “Hey X! I noticed you’ll be at the event Y in two weeks, and it looks like your company Z does a lot of N. I’m really curious about your opinion on N, do you think you can find 20 minutes to chat?”

If there is no attendee list, you can do the same thing for the speakers. Thankfully, they’re always public. By the way, try to become one! Identify the list of events you’d like to speak at and regularly submit proposals. If you get chosen as a speaker, ask your company to sponsor your travel. Being a speaker is a great way to meet a lot of interesting people quickly:

You may get invited to speaker-only dinners/parties. I met Martin Fowler in Budapest at an event like that.
You become recognizable on the floor - people will want to meet you. In some cases, they’ll line up with questions after your talk!

Also, don’t forget to find time to check in with people you already know! Just a minute with a friendly face goes a long way.

Community

You can’t always visit events; travelling can be hard and expensive. But likely, there are people in your community you’d like to connect with. So, just message them! If they’re local, offer to meet for a coffee. If not, offer to hang out over a call. It’s not as creepy as it sounds if you follow The Most Important Rule - offer to help with something. The worst thing that can happen? They’ll ghost you.

Your community can be anywhere: social media, Slack groups, development mailing lists, open-source maintainers, Reddit, etc.

Automating Essential Eight Compliance Checks with PowerShell

ShadowStrike — Sun, 26 Apr 2026 22:11:56 +0000

Version 1.0.0

If you work in Australian IT, cybersecurity, or digital forensics, you've encountered the Essential Eight. It's referenced in government procurement requirements, security assessments, incident response frameworks, and organisational policies across both public and private sectors.

The Australian Signals Directorate's Essential Eight is a set of eight baseline mitigation strategies designed to protect Windows environments against cyber threats. Checking compliance manually is time-consuming and error-prone. In this tutorial, you'll build a PowerShell script that automates Essential Eight audits, produces colour-coded console output, and writes detailed compliance reports to timestamped files.

What You'll Build

A PowerShell script called essential_eight.ps1 that checks a Windows system against all eight ASD mitigation strategies and produces a comprehensive audit report showing PASS/FAIL/WARN/INFO status for each control.

Prerequisites

PowerShell 5.1 or later (Windows 10+)
Administrator privileges recommended (some checks require elevated access)
No external modules or dependencies

Understanding the Essential Eight

Before building the script, it's worth understanding what each strategy actually checks. The ASD publishes detailed guidance, but the practical questions are:

1. Application Control — Is there a mechanism (AppLocker, Windows Defender Application Control) preventing unauthorised executables from running?

2. Patch Applications — Are third-party applications kept up to date? Is Windows Update active?

3. Configure Microsoft Office Macro Settings — Are macros restricted to prevent malicious Office documents from executing code?

4. User Application Hardening — Are legacy and high-risk features (Internet Explorer, Windows Script Host, PowerShell v2) disabled or restricted?

5. Restrict Administrative Privileges — Are admin accounts limited? Is UAC enabled? Are standard users running with least privilege?

6. Patch Operating Systems — Is the OS on a supported and current build?

7. Multi-Factor Authentication — Is MFA enforced, especially for privileged access?

8. Regular Backups — Are backups in place and recent? Are they protected from modification?

Each strategy has Maturity Levels (ML1, ML2, ML3) in the full ASD framework. This script focuses on ML1 baseline checks — the foundation that must exist before maturity level progression begins.

The Complete Script

Here's the full implementation (condensed for readability - full version on GitHub):

# Essential Eight Compliance Checker
# Author: ShadowStrike (Strategos)

param(
    [Parameter(Mandatory=$false)]
    [string]$OutputDir = ".",

    [Parameter(Mandatory=$false)]
    [switch]$Verbose
)

# Initialise report
$timestamp = Get-Date -Format "yyyyMMdd_HHmmss"
$outputFile = Join-Path $OutputDir "EssentialEight_Audit_$timestamp.txt"
$report = @()

# Track results
$passCount = 0
$failCount = 0
$warnCount = 0

function Write-Check {
    param([string]$Strategy, [string]$Check, [string]$Status, [string]$Detail = "")

    $color = switch ($Status) {
        "PASS" { "Green"; $script:passCount++ }
        "FAIL" { "Red"; $script:failCount++ }
        "WARN" { "Yellow"; $script:warnCount++ }
        "INFO" { "Cyan" }
    }

    $line = "[$Status] $Strategy - $Check"
    if ($Detail) { $line += ": $Detail" }

    Write-Host $line -ForegroundColor $color
    $script:report += $line
}

# STRATEGY 1: APPLICATION CONTROL
try {
    $appLockerPolicy = Get-AppLockerPolicy -Effective -ErrorAction Stop
    if ($appLockerPolicy.RuleCollections.Count -gt 0) {
        Write-Check "AppControl" "AppLocker Policy" "PASS" "Effective rules configured"
    } else {
        Write-Check "AppControl" "AppLocker Policy" "FAIL" "No effective rules"
    }
} catch {
    Write-Check "AppControl" "AppLocker Policy" "FAIL" "Not configured"
}

# STRATEGY 2: PATCH APPLICATIONS
$wuService = Get-Service -Name wuauserv -ErrorAction SilentlyContinue
if ($wuService -and $wuService.Status -eq "Running") {
    Write-Check "Patching" "Windows Update Service" "PASS" "Running"
} else {
    Write-Check "Patching" "Windows Update Service" "FAIL" "Not running"
}

# Check last update date
$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$history = $searcher.QueryHistory(0, 1) | Select-Object -First 1
$lastUpdate = $history.Date
$daysSince = (Get-Date) - $lastUpdate

if ($daysSince.Days -le 30) {
    Write-Check "Patching" "Last Update" "PASS" "$([math]::Round($daysSince.TotalDays)) days ago"
} else {
    Write-Check "Patching" "Last Update" "FAIL" "$([math]::Round($daysSince.TotalDays)) days ago (outdated)"
}

# STRATEGY 3: OFFICE MACRO SETTINGS
$excelPath = "HKCU:\Software\Microsoft\Office\16.0\Excel\Security"
if (Test-Path $excelPath) {
    $vbaWarnings = (Get-ItemProperty -Path $excelPath -Name VBAWarnings).VBAWarnings
    if ($vbaWarnings -eq 3 -or $vbaWarnings -eq 4) {
        Write-Check "MacroSettings" "Excel VBA" "PASS" "Restricted"
    } else {
        Write-Check "MacroSettings" "Excel VBA" "FAIL" "Unrestricted"
    }
}

# STRATEGY 4: USER APPLICATION HARDENING
$psv2 = Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root
if ($psv2.State -eq "Disabled") {
    Write-Check "Hardening" "PowerShell v2" "PASS" "Disabled"
} else {
    Write-Check "Hardening" "PowerShell v2" "FAIL" "Enabled (should be removed)"
}

$langMode = $ExecutionContext.SessionState.LanguageMode
if ($langMode -eq "ConstrainedLanguage") {
    Write-Check "Hardening" "PS Language Mode" "PASS" "ConstrainedLanguage"
} else {
    Write-Check "Hardening" "PS Language Mode" "WARN" "FullLanguage (unrestricted)"
}

# STRATEGY 5: RESTRICT ADMIN PRIVILEGES
$uacPath = "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System"
$uacEnabled = (Get-ItemProperty -Path $uacPath -Name EnableLUA).EnableLUA
if ($uacEnabled -eq 1) {
    Write-Check "Privileges" "UAC" "PASS" "Enabled"
} else {
    Write-Check "Privileges" "UAC" "FAIL" "Disabled"
}

# STRATEGY 6: PATCH OPERATING SYSTEMS
$os = Get-CimInstance Win32_OperatingSystem
$osBuild = $os.BuildNumber
if ([int]$osBuild -ge 19041) {
    Write-Check "OS Patching" "OS Support" "PASS" "Supported build"
} else {
    Write-Check "OS Patching" "OS Support" "FAIL" "Legacy build"
}

# STRATEGY 7: MULTI-FACTOR AUTHENTICATION
# Note: Full MFA assessment requires Azure AD audit
Write-Check "MFA" "Assessment" "INFO" "Requires directory-level audit"

# STRATEGY 8: REGULAR BACKUPS
$vssService = Get-Service -Name VSS
if ($vssService.Status -eq "Running") {
    Write-Check "Backups" "Volume Shadow Copy" "PASS" "Running"
} else {
    Write-Check "Backups" "Volume Shadow Copy" "WARN" "Not running"
}

# Write summary
Write-Host "`n[AUDIT SUMMARY]"
Write-Host "  PASS: $passCount" -ForegroundColor Green
Write-Host "  FAIL: $failCount" -ForegroundColor Red
Write-Host "  WARN: $warnCount" -ForegroundColor Yellow

$report | Out-File -FilePath $outputFile -Encoding UTF8

How to Use It

Troubleshooting: Execution Policy

If you see an error about scripts being disabled or not digitally signed:

Step 1: Set execution policy

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Step 2: Unblock the file if downloaded

Unblock-File .\essential_eight.ps1

Windows marks files downloaded from GitHub with Zone.Identifier metadata. Even with RemoteSigned policy, these files are blocked unless digitally signed or explicitly unblocked.

Check your current policy with Get-ExecutionPolicy -List.

Security Note: Read the Code Before You Run It

This script is not digitally signed. Code signing certificates cost $200-500/year and are unnecessary for open-source scripts where you can read the source code yourself.

Before running this or any PowerShell script:

Read it completely — every line, every function, every registry path
Understand what it does — does it match the stated purpose?
Check for risks — network calls, file deletions, credential access

Apply the ABC principle:

Assume nothing
Believe nothing
Check everything

A digital signature tells you WHO wrote code, not WHETHER it's safe. You are the final security control. Never execute code you haven't personally reviewed and understood.

Basic Audit

.\essential_eight.ps1

Runs the audit and writes report to EssentialEight_Audit_[timestamp].txt in the current directory.

Specify Output Directory

.\essential_eight.ps1 -OutputDir "C:\Compliance\Reports"

Run as Administrator

Some checks require elevated privileges. Right-click PowerShell → "Run as Administrator", then:

.\essential_eight.ps1

Understanding the Output

The script produces colour-coded console output:

[PASS] (green) - Control meets baseline requirements
[FAIL] (red) - Control does not meet requirements
[WARN] (yellow) - Partial compliance or requires manual review
[INFO] (cyan) - Informational finding, not a compliance check

Sample output (example system for demonstration - not real audit data):

[ESSENTIAL EIGHT COMPLIANCE AUDIT]
System: WORKSTATION-01

[STRATEGY 1: APPLICATION CONTROL]
[PASS] AppControl - AppLocker Policy: Effective rules configured
[INFO] AppControl - WDAC Policy: Not deployed (AppLocker in use)

[STRATEGY 2: PATCH APPLICATIONS]
[PASS] Patching - Windows Update Service: Running
[PASS] Patching - Last Update: 2026-04-18 - 6 days ago

[STRATEGY 3: OFFICE MACRO SETTINGS]
[PASS] MacroSettings - Excel VBA Warnings: Macros disabled (Value: 3)
[PASS] MacroSettings - Word VBA Warnings: Notification enabled (Value: 4)

[STRATEGY 4: USER APPLICATION HARDENING]
[PASS] Hardening - PowerShell v2: Disabled
[PASS] Hardening - PowerShell Version: v5.1
[WARN] Hardening - PowerShell Language Mode: FullLanguage (unrestricted)
[PASS] Hardening - Script Block Logging: Enabled

[STRATEGY 5: RESTRICT ADMINISTRATIVE PRIVILEGES]
[PASS] Privileges - Current User Role: Running as standard user
[PASS] Privileges - UAC Status: Enabled
[PASS] Privileges - Local Administrators: 2 account(s) - acceptable range

[STRATEGY 6: PATCH OPERATING SYSTEMS]
[INFO] OS Patching - Operating System: Microsoft Windows 10 Pro (Build 19045)
[PASS] OS Patching - OS Support Status: Windows 10 version 2004+ (supported)

[STRATEGY 7: MULTI-FACTOR AUTHENTICATION]
[INFO] MFA - Windows Hello: Credential provider detected
[INFO] MFA - Credential Providers: 3 provider(s) registered
[INFO] MFA - Note: Full MFA assessment requires Azure AD / Active Directory audit

[STRATEGY 8: REGULAR BACKUPS]
[INFO] Backups - Windows Backup Service: Not active (may use third-party)
[PASS] Backups - Volume Shadow Copy: Running
[PASS] Backups - Latest Shadow Copy: 2026-04-23 - 1 days ago

[AUDIT SUMMARY]
  PASS: 15
  FAIL: 0
  WARN: 1

The timestamped report file contains the same information in plain text format for archiving.

Code Walkthrough

Strategy 1: Application Control

Checks for AppLocker or Windows Defender Application Control (WDAC):

$appLockerPolicy = Get-AppLockerPolicy -Effective
if ($appLockerPolicy.RuleCollections.Count -gt 0) {
    Write-Check "AppControl" "AppLocker Policy" "PASS" "Effective rules configured"
}

AppLocker policies can be deployed via Group Policy or locally. The -Effective parameter returns the combined result of all policies affecting the system.

For WDAC, the script checks for policy files in C:\Windows\System32\CodeIntegrity\CiPolicies\Active\.

Strategy 2: Patch Applications

Verifies Windows Update service is running and checks last update date:

$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$history = $searcher.QueryHistory(0, 1) | Select-Object -First 1
$lastUpdate = $history.Date
$daysSince = (Get-Date) - $lastUpdate

The Windows Update COM API provides detailed patch history. This check flags systems where the last update was >30 days ago as outdated.

Strategy 3: Office Macro Settings

Checks registry settings for Excel and Word macro behaviour:

$excelPath = "HKCU:\Software\Microsoft\Office\16.0\Excel\Security"
$vbaWarnings = (Get-ItemProperty -Path $excelPath -Name VBAWarnings).VBAWarnings

VBAWarnings values:

1 = Enable all macros (dangerous)
2 = Disable all with notification
3 = Disable all except digitally signed
4 = Disable all without notification (most secure)

Values 3 and 4 meet Essential Eight ML1 baseline.

Strategy 4: User Application Hardening

Multiple checks including PowerShell v2 removal and script block logging:

$psv2 = Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root
if ($psv2.State -eq "Disabled") {
    Write-Check "Hardening" "PowerShell v2" "PASS" "Disabled"
}

PowerShell v2 lacks modern security features (script block logging, Constrained Language Mode support) and should be removed from all systems.

Script block logging check:

$scriptBlockPath = "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
$scriptBlockEnabled = (Get-ItemProperty -Path $scriptBlockPath -Name EnableScriptBlockLogging).EnableScriptBlockLogging

When enabled (value = 1), all PowerShell script execution is logged to Windows Event Log, providing audit trails for forensic investigation.

Strategy 5: Restrict Administrative Privileges

Checks UAC status and local administrator count:

$uacPath = "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System"
$uacEnabled = (Get-ItemProperty -Path $uacPath -Name EnableLUA).EnableLUA

$admins = Get-LocalGroupMember -Group "Administrators"

UAC (User Account Control) prompts for elevation when administrative actions are attempted. Disabling UAC is a common misconfiguration that violates Essential Eight requirements.

The administrator count check flags systems with excessive admin accounts. Typically, only built-in Administrator and one domain admin account should exist on workstations.

Strategy 6: Patch Operating Systems

Verifies OS is on a supported build:

$os = Get-CimInstance Win32_OperatingSystem
$osBuild = $os.BuildNumber

if ([int]$osBuild -ge 19041) {
    Write-Check "OS Patching" "OS Support" "PASS" "Supported build"
}

Build 19041 = Windows 10 version 2004, the minimum currently-supported consumer version. Enterprise LTSC versions may have different support timelines.

Strategy 7: Multi-Factor Authentication

MFA assessment requires directory-level audit (Azure AD, Active Directory):

$credProviders = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers"

The script checks for Windows Hello and registered credential providers, but full MFA enforcement validation requires checking conditional access policies in Azure AD or examining GPO settings for smart card requirements.

Strategy 8: Regular Backups

Checks Volume Shadow Copy Service and recent shadow copies:

$shadows = Get-CimInstance Win32_ShadowCopy | Where-Object { $_.VolumeName -like "*C:*" }
$latestShadow = $shadows | Sort-Object InstallDate -Descending | Select-Object -First 1
$daysSince = (Get-Date) - $latestShadow.InstallDate

Shadow copies are point-in-time snapshots used for System Restore and file recovery. The script flags systems where the latest shadow copy is >7 days old.

Real-World Use Cases

Pre-audit preparation: Run this script on sample systems before formal compliance assessments to identify gaps early.

Continuous monitoring: Schedule the script as a daily task and email the report to security teams. Track compliance drift over time.

Incident response baseline: After a security incident, run the script on affected systems to document Essential Eight posture at the time of compromise.

Procurement verification: When deploying new workstations, run the audit to verify vendor configuration meets baseline requirements before acceptance.

Maturity level progression: Use the baseline audit results to identify systems ready for ML2/ML3 implementation.

Extending the Script

HTML report generation: Replace the plain-text output with an HTML file including coloured tables and charts.

Email integration: Add Send-MailMessage to automatically email reports to compliance teams.

Remote execution: Wrap the script in Invoke-Command to audit multiple systems from a central management workstation.

SIEM integration: Parse the output and send findings to a SIEM platform for centralised compliance monitoring.

Remediation actions: Add a -Remediate switch that automatically fixes common failures (enable UAC, remove PowerShell v2, enable script block logging).

Maturity Levels Beyond ML1

This script focuses on ML1 (baseline) checks. The ASD Essential Eight Maturity Model has three levels:

Maturity Level 1: Partly aligned with intent. Baseline controls exist but may not be comprehensive.

Maturity Level 2: Mostly aligned with intent. Controls cover most assets and attack vectors.

Maturity Level 3: Fully aligned with intent. Comprehensive controls across all assets with robust monitoring.

Progression from ML1 → ML2 → ML3 requires increasingly stringent technical controls and centralised management. For example:

Application Control ML1: AppLocker with basic rules
Application Control ML2: Centralised AppLocker or WDAC with allow-listing
Application Control ML3: WDAC with cryptographic verification of all executables

This script provides the ML1 foundation. Assessing ML2/ML3 compliance requires additional checks beyond what local PowerShell can determine (requires SCCM, Intune, or GPO reporting).

GitHub Repository

The complete script, sample reports, and this tutorial are available on GitHub:

ShadowStrike-CTF / essential-eight-checklist

PowerShell scripts for practical Essential Eight compliance checking on Windows systems.

essential-eight-checklist

PowerShell scripts for practical Essential Eight compliance checking on Windows systems.

View on GitHub

Conclusion

Essential Eight compliance doesn't require expensive enterprise tools. PowerShell provides native cmdlets for checking application control, patching status, user hardening, privilege restrictions, and backup configurations.

This script packages those checks into a practical audit workflow that runs on any Windows 10/11 system without dependencies. For IT security professionals, compliance teams, and system administrators working in Australian government or enterprise environments, automated Essential Eight auditing is a fundamental operational requirement.

The value isn't just in the compliance report — it's in the velocity. Running this audit manually would take an experienced admin 30-60 minutes per system. The script completes it in seconds and produces consistent, auditable results.

Built by ShadowStrike (Strategos) — where we build actual security tools instead of theatre 🎃.

Proseflow: Stop Writing Changelogs by Hand (We Built an AI for That)

shiplog-bot — Sun, 26 Apr 2026 22:03:17 +0000

The Problem: Changelogs suck to write. You finish a sprint, merged 47 pull requests, squashed bugs, shipped features, and now you have to sit down and manually turn all that into a coherent narrative that makes sense to three different audiences: developers who care about technical details, users who care about what changed, and executives who care that something changed.

It's boring. It's repetitive. It's the kind of task that makes you question your life choices.

I built Proseflow because I was tired of this. And honestly? So was an AI agent I set loose on the problem.

What is Proseflow?

It's a free, open-beta AI changelog generator that connects directly to your GitHub repository. Pick your repo, pick your date range, hit a button, and get back three different versions of your changelog—one for developers, one for users, and one for executives—ready to copy, download, or ship wherever you need it.

No more staring at a blank document. No more wondering how to phrase "we fixed the thing that was broken." No more choosing between technical accuracy and readability.

How It Works

Step 1: GitHub OAuth
Click "Sign in with GitHub." We use NextAuth to handle the OAuth flow. No passwords, no sketchy API tokens sitting in your .env file. Just your GitHub account.

Step 2: Pick Your Repo
Select from your repositories (public or private—we can access both if you grant permissions).

Step 3: Pick Your Date Range
Choose when you shipped the last version and when you're shipping the next one. We'll grab all the commits and PRs in between.

Step 4: Let AI Do the Thing
We send the commit history to OpenAI's GPT-4o-mini, which generates three distinct versions:

Developer: Technical, includes commit hashes, breaking changes, API updates, performance improvements
User-Friendly: Plain English, focuses on what users can do differently, drops the jargon
Executive: High-level impact, mentions new capabilities and business value, keeps it brief

Step 5: Copy, Download, Ship
Click to copy any version to your clipboard or download as markdown. Paste into your README, email, release notes—wherever.

The Tech Stack

Frontend & Backend: Next.js. Simple, fast, one codebase.

Auth: NextAuth with GitHub OAuth. You authenticate, we get read access to your repos, we keep things secure.

The AI Magic: OpenAI's GPT-4o-mini. It's fast, affordable, and surprisingly good at understanding commit messages and turning them into coherent prose across different tones.

The whole thing runs on Vercel. Deployment is automatic. It's 2025. We're not running servers in our garage.

Why This Exists

Changelogs are important. They're how you communicate what you've shipped. But they're boring to write, so people either skip them, phone them in, or spend hours crafting the perfect version.

We wanted to automate the grunt work. Let you spend your time building, not writing about building.

It's free because we built it as a proof of concept (with some help from an autonomous AI agent, which is a fun story for another day). We want to see if it's useful. If it is, we'll keep it free or find a sustainable model that doesn't require a subscription to generate a changelog.

Try It

Head over to https://proseflow-v1.vercel.app and give it a shot.

It takes 2 minutes to generate your first changelog. If it saves you 30 minutes of writing, that's a win.

If it's broken, tell me. If it's useful, tell other people. If you have ideas for what it should do next, I'm listening.

Status: Free, in beta, actively maintained. Built by an indie dev (with AI assistance) who got tired of writing changelogs.

Future

The Real Token Economy Is Not About Spending Less. It Is About Thinking Smaller.

Tokens are not just money

Balance does not mean symmetry

The real problem is overloaded cognition

Think smaller, not just cheaper

The 20 field JSON problem

Smaller prompts reduce variance

Where OrKa fits into this

Token metrics should trigger questions

A simple mental model

This is also a model selection problem

Token economy as observability

The wrong future

The better future

Final thought

Built a native MCP server for Odoo so Claude, Cursor, and Codex can drive it directly

Per-key scopes, rate limits, and audit log

Custom tools without leaving the UI

MCP-tagged chatter

Links

The Bug That Cost Me Three Weeks: Why Your SL/TP Logic Is Probably Wrong

The Naive Implementation

Failure Mode 1: Flag-Based Checking Doesn't Track What Actually Happened

Failure Mode 2: Re-Entry on the Next Tick

The Correct Mental Model

Why Backtesting Misses This

The Actual Production Failure

What I Learned

on the plane, again

thesis

context

argument

tension or counterpoint

closing

further reading

related on this site

logic

thesis

context

a few familiar gates

argument

logic is a thinking tool, not a coding tool

where it pays off in normal life

the tool never goes out of style

applying it broadly is what makes it powerful

learn it as early as you can

the butterfly effect of better decisions

tension or counterpoint

closing

further reading

related on this site

My Wallet Experiences

I Saved 2 Hours a Week by Automating My Changelog — Here's Exactly How

The Problem (Before)

The Solution (After)

Real Example: Before → After

How It Actually Works

1. GitHub OAuth (via NextAuth)

2. Commit Intelligence (GPT-4o-mini)

3. One-Click Export

The Technical Stack

Real Time Savings

Being Honest About What This Is

Try It

Authenticating AI Agents Without Shared Secrets

The credentials problem nobody's fixing

What agents actually need

Ed25519 JWT: the boring solution

How agents pay for things

What production feedback says

What no framework ships

How Identity Actually Works on Solana

Beyond Passwords: Understanding Identity on Solana

Think of it Like an SSH Key

Why Addresses Look So Weird

You Are the Only Boss

One Key for Everything

How to Grow Your Network

What is Network?