Venkai Blog

Agent Task Decomposition: Ordered, Verifiable Subtasks

*Methodology article for agent builders. No financial content.*

An agent given a goal like "ship a pricing page" will fail in predictable ways: it writes code it never runs, it marks tasks done without checking output, it loops on the same step. Task decomposition is the fix — turning a goal into an ordered graph of subtasks where each one is self-contained, verifiable, and has explicit failure handling.

## The three properties that matter

1. **Self-contained**: an agent reading only the task description knows exactly what to do. No hidden context from the goal or sibling tasks. 2. **Verifiable**: "done" means observable output — a file exists, a command exits 0, a test passes. Not "I think it's done." 3. **Ordered by dependency**: task B that consumes task A's output lists A as a dependency. No circular dependencies. Ever.

## Verification is the part everyone skips

Trust a self-reported "done" and you will ship broken work. Every task should name its expected outcome: a path, a status code, a test count. Check that the output exists before marking the task complete. This is not bureaucracy — it is the difference between a colony that ships and a colony that hallucinates shipping.

## Failure handling, written down in advance

For each subtask: what happens if it fails? Retry (transient errors), reassign (agent unreliable), replan (task impossible as specified), or fail the goal. Writing this *before* execution prevents the most common agent pathology: retrying forever and burning budget on a task that was never feasible.

## Where to get the skill

The full task-decomposer skill — decomposition templates, verification patterns, failure ladders — ships in the Skills Pack (43 EUR).

Clipping and Honesty: What Short-Form Can and Cannot Do

*Methodology article. Not financial advice. Trading involves risk of loss where markets are discussed.*

Short-form clipping — cutting long content into vertical clips — is distribution, not magic. Done honestly it extends the reach of real work. Done dishonestly it is a spam cannon that burns your name. This article states what our Clipping Lab does and refuses to do.

## What a clip plan can do

Given a transcript, a good clip planner scores candidate segments on surface signals: does the segment contain a concrete question, a number worth keeping, a contrast, a self-contained arc within a time budget. These are *hook signals* — indicators that a segment is worth watching, not guarantees anyone will watch it.

## What it cannot do

It cannot promise views, followers, or revenue. It cannot predict virality. Anyone selling you clip counts or outcome guarantees is selling you a story. Honest tooling outputs a ranked plan with its scoring criteria visible — you decide what to publish.

## The honesty rules we hold

- No fabricated hooks. If the clip does not contain the claim, the caption does not get to invent it. - No fake urgency, no invented metrics, no "this clip will change your life." - When markets appear: the risk disclaimer appears. Every time.

## Where to get it

Clipping Lab (clip planning API — transcript in, scored clip plan out) is part of the Venkai tooling line at venkai.fr. The operator playbook for running clips honestly is in the Skills Pack (43 EUR).

What Is a "Sniper Range"? An Honest Guide to Range Compression

*Not financial advice. Trading involves risk of loss. This article describes measurement methodology only — no trade setups, no predictions.*

"Sniper range" is our name for a plain idea: a market range that has compressed enough that its boundaries are worth *measuring carefully* — not predicting, measuring. This article explains what we measure, why compression matters statistically, and — just as important — what the concept cannot do for you.

## Ranges are facts, breakouts are stories

A range is directly observable: price has been oscillling between a high and a low over a lookback window. That's data. What people *extrapolate* from ranges — "it's coiling for a breakout", "it's about to explode" — is a story. Stories can be wrong in ways data can't.

The honest framing: a compressed range tells you where liquidity and stops *tend* to cluster (near the boundaries), and that volatility is currently low. It tells you nothing about direction, timing, or whether a breakout will follow at all. Plenty of compressed ranges simply continue.

## What we actually measure

Our Sniper Range scanner (`sniper_range.py`, part of Trading Lab) reads OHLCV CSV and reports:

1. **Range position** — where the current close sits between the lookback high and low (0–100%). Descriptive, not predictive. 2. **Compression flags** — is the recent range small relative to its own history? A simple percentage threshold you choose. There is no "correct" threshold; different thresholds describe different things. 3. **Volume context** — volume within the range versus its average. Again: description, not inference.

That's the whole tool. It makes no forecasts and draws no arrows on charts. Its value is that it prevents *you* from fooling *you*: the numbers are the numbers.

## What "no lookahead" means and why it matters

If you test any range-based idea on historical data, the cardinal sin is lookahead: using information that wasn't available at the simulated decision time. Walk-forward evaluation — testing only on data that comes after your training window — is the minimum discipline. Even then, a backtest only shows what *would have* happened to one rule in one past sample. It is not evidence of future returns. Anyone telling you otherwise is selling you a story.

## Who this is for

Traders and analysts who want a measurement tool and an operating discipline, not a signal service. If you want to be told when to buy, this is not for you — and no honest tool should be.

## Where to get it

The Sniper Range scanner, its PLAYBOOK (how to read the output without fooling yourself), and a worked demo on sample data are part of Trading Lab (238 EUR). If you only want the methodology skills, the Skills Pack (43 EUR) covers market structure and walk-forward discipline.

Walk-Forward Backtesting Without Fooling Yourself

*Not financial advice. Trading involves risk of loss. This article describes evaluation methodology only — no predictions, no returns claims.*

Most backtests fool their author. The strategy is tuned on the whole dataset, tested on the same data it was tuned on, and reported with a beautiful equity curve. Walk-forward backtesting is the minimum discipline that prevents this — and even then, it can't promise you anything about the future. Here is what it actually is, and what it can and cannot do.

## The core problem: lookahead

Lookahead means using information at decision time that wasn't available then. It sneaks in everywhere: indicators computed over the full series, parameters chosen after seeing the results, "in-sample" rules quietly informed by "out-of-sample" data. If your test set influenced your decisions, it is not a test set.

## Walk-forward in one paragraph

Split your timeline into ordered blocks. Tune your rules on block 1 only, then evaluate on block 2 — data the tuning never saw. Then tune on blocks 1–2, evaluate on block 3. And so on. Every evaluation happens strictly after its training window. That's it. The word "walk-forward" just means the train/test boundary keeps moving forward in time.

Two details matter more than they sound:

1. **Every test block must be non-empty.** An off-by-one that gives you an empty final test block silently converts your "evaluation" into nothing. 2. **Chronological order is the whole point.** Shuffling rows to make the split "cleaner" destroys the only property that makes the exercise meaningful.

## What a walk-forward result is — and isn't

A walk-forward result is a *description*: "this rule set, evaluated this way on this historical sample, produced these numbers." It is not:

- Evidence the strategy will make money. The future is not a sample of the past. - A guarantee of robustness. Markets change regimes; parameters tuned in one regime may mean nothing in the next. - A license to skip thinking. A correct evaluation of a bad idea is still a bad idea.

What it *is* good for: killing bad ideas cheaply and preventing self-deception about methodology. That's genuinely valuable — most "amazing" backtests die the moment lookahead is removed.

## A minimal honest workflow

1. Define rules and parameter ranges **before** looking at evaluation results. 2. Use ordered blocks, train only on the past, evaluate only on the future. 3. Report every split, not just the best one. The spread between splits is information. 4. Treat the whole exercise as process verification, not forecasting.

## Where to get the tooling

The walk-forward splitter with no-lookahead guarantees (`walkforward_splits`) ships in the Pro Toolkit (94 EUR), with a 7-test suite that asserts no lookahead and non-empty test blocks. The methodology itself — including how to read results without fooling yourself — is covered in the Skills Pack (43 EUR).