DEV Community: l3o6

Some Decision-Making Methods for System One Models Like Jev

l3o6 — Sun, 20 Sep 2026 08:31:25 +0000

When working with System One models like Jev, we may need decision-making algorithms such as Multi-Criteria Decision Making (MCDA).

Unlike ML, MCDA uses predefined criteria and weights. This usually makes its decisions more transparent and easier to understand, and it can work even with a small amount of data. Common MCDA methods include WSM and TOPSIS. However, MCDA depends on subjective weights and criteria, adapts poorly to changes, and becomes more complex when there are many alternatives. ML, on the other hand, learns from data, finds patterns, works well with large and complex datasets, and can adapt when new data arrives. However, it depends on data quality, requires more computing resources, and is often harder to interpret.

WSM - Weighted Sum Method

WSM is a method where each criterion gets a weight. The value of an alternative for each criterion is multiplied by its weight, and all results are added together. The higher the final score, the better the alternative.

https://www.geeksforgeeks.org/dsa/weighted-sum-method-multi-criteria-decision-making/

import numpy as np

# Alternatives matrix.
# Each row represents one student.
# Column 0: CGPA, or average grade.
# Column 1: Stipend, or required cost.
# Column 2: Technical Exam score.
# Column 3: Aptitude Test score.
X = np.array([
    [9.0, 12000, 72, 3],
    [7.6,  8500, 68, 3],
    [8.2,  9500, 63, 2],
    [8.5, 10000, 70, 4],
    [9.3, 14000, 72, 4]
])

# Criterion weights: CGPA = 30%, Stipend = 20%, Technical Exam = 25%, Aptitude Test = 25%.
weights = np.array([0.3, 0.2, 0.25, 0.25])

# True means a higher value is better, and False means a lower value is better.
benefit = [True, False, True, True]

# Copy the original data for normalization.
N = X.copy()

for j in range(X.shape[1]):
    if benefit[j]:
        # For a criterion that must be maximized, divide each value by the maximum value in the column.
        # Example result: [0.968, 0.817, 0.882, 0.914, 1.000].
        N[:, j] = X[:, j] / X[:, j].max()
    else:
        # For a criterion that must be minimized, divide the minimum value by each value in the column.
        # Stipend example: [12000, 8500, 9500, 10000, 14000].
        # 8500 / 12000 = 0.708.
        # 8500 / 8500 = 1.000.
        # 8500 / 9500 = 0.895.
        # 8500 / 10000 = 0.850.
        # 8500 / 14000 = 0.607.
        # Example result: [0.708, 1.000, 0.895, 0.850, 0.607].
        # The smallest value gets 1 because a lower value is better for this criterion.
        N[:, j] = X[:, j].min() / X[:, j]

# Multiply each normalized value by its criterion weight and add all values together.
scores = N @ weights

print("Scores:", scores)

# Find the index of the highest final score and add 1 because Python indexes start from 0.
best = scores.argmax() + 1

print("Best student:", best)

And here is an additional example of using WSM specifically with Jev - incident response. Suppose that after a new release, checkout errors increase, and we need to choose between rolling back the release, disabling the faulty feature via a feature flag, or preparing a hotfix. Jev can evaluate each option based on criteria such as recovery speed, safety, customer impact, and implementation ease, while WSM combines those scores using predefined weights. Hard constraints can also be applied before selecting an action - for example, excluding options whose safety score falls below an acceptable threshold.

import os
import requests

API_KEY = os.environ["OPENROUTER_API_KEY"]

state = """
After release v2.4, checkout errors increased to 18%.
The previous version is stable.
The faulty feature can be disabled with a feature flag.
A hotfix is estimated to require code changes and a new deployment.
"""

actions = [
    "rollback",
    "disable_feature",
    "hotfix",
]

criteria = {
    "recovery_speed": {
        "instructions": "How quickly would {action} restore normal service?",
        "criteria": ["very_slow", "slow", "medium", "fast", "very_fast"],
    },
    "safety": {
        "instructions": "How safe is {action} in this incident?",
        "criteria": ["very_risky", "risky", "neutral", "safe", "very_safe"],
    },
    "customer_impact": {
        "instructions": "How effectively would {action} reduce customer impact?",
        "criteria": ["very_low", "low", "medium", "high", "very_high"],
    },
    "implementation_ease": {
        "instructions": "How easy is {action} to execute?",
        "criteria": ["very_hard", "hard", "medium", "easy", "very_easy"],
    },
}

weights = {
    "recovery_speed": 0.40,  # Recovery is the most important factor
    "safety": 0.30,
    "customer_impact": 0.20,
    "implementation_ease": 0.10,
}

results = {}

for action in actions:
    questions = {}

    for criterion, config in criteria.items():
        question_name = f"{action}_{criterion}"
        questions[question_name] = {
            "type": "score",
            "instructions": config["instructions"].format(action=action),
            "criteria": config["criteria"],
        }

    response = requests.post(
        "https://openrouter.ai/api/alpha/decisions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": "~typesafe/jev-latest",
            "state": state,
            "questions": questions,
        },
    )

    answers = response.json()["answers"]

    scores = {
        criterion: answers[f"{action}_{criterion}"]["score"] for criterion in criteria
    }

    wsm_score = sum(scores[criterion] * weights[criterion] for criterion in weights)

    normalized_wsm = wsm_score / 4  # Normalize to a 0-1 scale (assuming max score is 4)

    results[action] = {
        "scores": scores,
        "wsm": wsm_score,
        "utility": normalized_wsm,
    }


MIN_SAFETY_SCORE = 2

eligible_results = {
    action: result
    for action, result in results.items()
    if result["scores"]["safety"] >= MIN_SAFETY_SCORE
}


if not eligible_results:
    best_action = "human_review"
else:
    best_action = max(
        eligible_results,
        key=lambda action: results[action]["wsm"],
    )

print(best_action)

In my case, disable_feature was chosen.

TOPSIS - Technique for Order Preference by Similarity to Ideal Solution

In TOPSIS, the values for all criteria are first normalized and then multiplied by their weights. After that, the ideal best and ideal worst values are found for each criterion. The distance from each alternative to the ideal best and ideal worst solutions is calculated, and then the closeness score is found. The higher this score, the better the alternative.

https://www.geeksforgeeks.org/machine-learning/topsis-method-for-multiple-criteria-decision-making-mcdm/

import numpy as np
import pandas as pd

# Input data.
df = pd.DataFrame({
    "Phone":   ["A", "B", "C", "D"],
    "RAM":     [4, 6, 6, 8],
    "Memory":  [128, 64, 128, 256],
    "Display": [6.5, 6.4, 6.8, 7.0],
    "Battery": [3500, 3800, 4200, 5000],
    "Price":   [15000, 16000, 19000, 25000]
})

matrix = df[
    ["RAM", "Memory", "Display", "Battery", "Price"]
].to_numpy(dtype=float)

# Criterion weights: RAM = 10%, Memory = 10%, Display = 20%, Battery = 20%, Price = 40%.
# A larger weight means the criterion has more influence on the final result.
# Price = 0.4 means that price has more influence than RAM = 0.1.
weights = np.array([0.1, 0.1, 0.2, 0.2, 0.4])

# +1 means a higher value is better, and -1 means a lower value is better.
impacts = np.array([1, 1, 1, 1, -1])

# Normalization is needed because the criteria use different scales.
# Example scales: RAM is about 4-8, Battery is about 3500-5000, and Price is about 15000-25000.
column_norms = np.sqrt(np.sum(matrix ** 2, axis=0))
normalized = matrix / column_norms

# Example normalized matrix.
# normalized = [
#     [0.3244, 0.4000, 0.4866, 0.4203, 0.3916],  # A
#     [0.4867, 0.2000, 0.4791, 0.4564, 0.4177],  # B
#     [0.4867, 0.4000, 0.5090, 0.5044, 0.4961],  # C
#     [0.6489, 0.8000, 0.5240, 0.6005, 0.6527]   # D
# ]

# Apply the weights so more important criteria have more influence on TOPSIS distances.
weighted = normalized * weights

# Example weighted matrix.
# weighted = [
#     [0.03, 0.04, 0.09, 0.08, 0.15],  # A
#     [0.05, 0.02, 0.08, 0.09, 0.16],  # B
#     [0.05, 0.04, 0.09, 0.10, 0.19],  # C
#     [0.07, 0.08, 0.10, 0.12, 0.25],  # D
# ]

# Ideal Best uses MAX for positive criteria and MIN for negative criteria such as Price.
best = np.where(
    impacts == 1,
    weighted.max(axis=0),
    weighted.min(axis=0)
)

# Example Ideal Best: [0.07, 0.08, 0.10, 0.12, 0.15].
# Ideal Worst uses the opposite values.
worst = np.where(
    impacts == 1,
    weighted.min(axis=0),
    weighted.max(axis=0)
)

# Example Ideal Worst: [0.03, 0.02, 0.08, 0.08, 0.25].
# A good alternative should be close to Ideal Best and far from Ideal Worst.
distance_to_best = np.linalg.norm(weighted - best, axis=1)
distance_to_worst = np.linalg.norm(weighted - worst, axis=1)

# TOPSIS score = distance_to_worst / (distance_to_best + distance_to_worst).
# A score closer to 1 is better.
score = (
    distance_to_worst /
    (distance_to_best + distance_to_worst)
)

df["Distance Best"] = distance_to_best
df["Distance Worst"] = distance_to_worst
df["TOPSIS Score"] = score

print("\nDistances and TOPSIS Score:")
print(
    df[
        ["Phone", "Distance Best", "Distance Worst", "TOPSIS Score"]
    ].round(4)
)

# Example result:
#   Phone  Distance Best  Distance Worst  TOPSIS Score
# 0     A         0.0633          0.1063        0.6269
# 1     B         0.0699          0.0957        0.5778
# 2     C         0.0631          0.0701        0.5260
# 3     D         0.1044          0.0777        0.4265
# The alternative with the highest TOPSIS Score gets first place.
# A = 0.6269.

Choosing a Method

Method	When to use	Example: supplier selection
WSM	Use it when the weights are already known, the criteria can be normalized, and simple compensation is acceptable, meaning a poor result for one criterion can be balanced by a good result for another.	`Score = Price×0.2 + Quality×0.4 + Delivery×0.25 + Support×0.15`
TOPSIS	Use it when the weights are already known and you want an alternative that is close to the best values for all criteria and far from the worst values.	Choose the supplier whose Price/Quality/Delivery/Support profile is closest to the ideal profile.

Routing OpenCode Tasks with Jev

l3o6 — Fri, 18 Sep 2026 18:50:05 +0000

After the release of the TypeSafe AI Jev model and its availability in OpenRouter, I decided to immediately test its capabilities and rewrite my minimalist model router in OpenCode. To do this, I wrote a tool for OpenCode that sends requests to Jev through the OpenRouter API.

The main idea is to build the solution based on three criteria.
After testing the classifier on about a hundred different requests, I settled on the following instructions:

Coordination
"Does successful implementation require reasoning about interactions or coordinated behavior across multiple parts of the system, rather than merely making localized changes in more than one file or module?"
Uncertainty
"Does successful implementation require open-ended investigation to discover an unknown root cause, bottleneck, design, or implementation strategy, rather than following a bounded diagnostic procedure with clear tools and success criteria?"
Consequences
"Would an incorrect implementation have significant consequences, such as broad regressions, compatibility breakage, security issues, or data loss?"

These have currently shown the greatest effectiveness.

Next, I calculate complexity as the maximum of two criteria: coordination and uncertainty. And a threshold value that depends on the consequences. The more serious the consequences, the lower the threshold value and the higher the probability that a powerful model will be used to solve the task. If complexity is greater than or equal to the threshold value, the powerful model is selected; otherwise, the weaker one is selected.

While developing this tool, I used ideas from several sources. I will quote them below:

"Rather than ask a model to solve the entire problem in one shot, we ask independent narrow questions and defer to code where possible. [...] The results are then used programmatically to produce the output actions."

https://evals.typesafe.ai/

"The most reliable real-world workflows tend to have many independent, decomposed questions, with fine-grained behavior that's dependent on probabilities instead of discrete decisions."

"Jev outputs all probabilities in parallel instead of autoregressively generating by token."

"The end result is discrete branching, but how we get to a final answer involves a lot of domain-specific engineering that needs to be done highly consistently."

https://typesafe.ai/blog/introducing-system-one-models-and-jev

"Each prompt was evaluated [...] and returned a structured JSON object containing scores for seven criteria [...] These scores constituted a computable prompt-level vector used by the routing rule. [...] consists of calculating the total weighted score of each decision alternative and then selecting the alternative with the highest final value."

https://www.mdpi.com/2078-2489/17/6/539

The complete source code of the tool:

// .config/opencode/tools/jev_route.ts

import { tool } from "@opencode-ai/plugin";

const apiKey = process.env.OPENROUTER_API_KEY;

if (!apiKey) {
  console.error(
    "Missing OPENROUTER_API_KEY environment variable. Please set it to your OpenRouter API key.",
  );
  process.exit(1);
}

export default tool({
  description:
    "Classifies an approved implementation plan and returns either lite or build.",
  args: {
    plan: tool.schema
      .string()
      .describe("The complete approved implementation plan"),
  },
  async execute({ plan }) {
    const response = await fetch("https://openrouter.ai/api/alpha/decisions", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        model: "~typesafe/jev-latest",
        state: `
Approved implementation plan:
${plan}

If uncertain, choose build.
        `,
        questions: {
          coordination: {
            type: "noul",
            instructions:
              // "Does successful implementation require coordinating behavior or changes across multiple parts of the system?",
              "Does successful implementation require reasoning about interactions or coordinated behavior across multiple parts of the system, rather than merely making localized changes in more than one file or module?",
          },

          uncertainty: {
            type: "noul",
            instructions:
              // "Does successful implementation require resolving substantial uncertainty, such as an unknown root cause, unclear design choice, or missing implementation strategy?",
              // "Does successful implementation require first discovering the root cause, bottleneck, correct design, or implementation strategy because it is not already known from the plan?",
              "Does successful implementation require open-ended investigation to discover an unknown root cause, bottleneck, design, or implementation strategy, rather than following a bounded diagnostic procedure with clear tools and success criteria?",
          },

          consequence: {
            type: "noul",
            instructions:
              "Would an incorrect implementation have significant consequences, such as broad regressions, compatibility breakage, security issues, or data loss?",
          },
        },
      }),
    });

    const { answers } = await response.json();

    const complexity = Math.max(
      answers.coordination.noul,
      answers.uncertainty.noul,
    );

    const threshold = answers.consequence.noul >= 0.7 ? 0.4 : 0.65;

    return complexity >= threshold ? "build" : "lite";
  },
});

The orchestration agent is forbidden from taking any actions other than calling one tool and delegating the task. Route agent configuration:

---
description: Routes tasks to the appropriate implementation agent
mode: primary
model: openai/gpt-5.6-luna
permissions:
  - action: "*"
    resource: "*"
    effect: deny

  - action: subagent
    resource: Build
    effect: allow

  - action: subagent
    resource: Lite
    effect: allow

  - action: jev_route
    resource: "*"
    effect: allow
---

You are a task orchestrator.

Planning is complete. Treat the latest plan as approved.

1. Call `jev_route` with the latest approved plan.
2. It returns `lite` or `build`.
3. Delegate the implementation to that subagent.
4. Do not override the routing decision.
5. Do not implement the task yourself.
6. After completion, verify the result and respond concisely.

This is much faster and cheaper than using "thinking" models. It is too early to draw final conclusions, but the initial results look promising. I will observe how it goes.

Fuzz Testing for Java Code Generation

l3o6 — Wed, 16 Sep 2026 15:33:23 +0000

Fuzz testing can effectively complement unit and integration tests in code-generation tasks performed by agents by providing automatically discovered counterexamples. This is especially useful for integration components that process external data, such as interactions with external APIs, where the space of possible inputs is often too large to cover manually, and where it is important to assess the client's robustness against a wide range of valid, malformed, and unexpected inputs.

By receiving failures and stack traces as feedback, the agent gets a much stronger feedback loop than with example-based tests alone. Fuzzing can uncover issues caused by malformed data, boundary values, unusual strings, missing fields, and rare combinations of otherwise valid parameters.

Research on LLM-generated code suggests that this approach is promising. Execution-based feedback has been shown to help with automated code generation and repair, while studies on differential fuzzing show that fuzzing can detect behavioral regressions in LLM-generated code that existing test suites may miss. There are also studies where fuzzing is integrated directly into agentic testing workflows.

Jazzer is a coverage-guided fuzzer for the JVM. It mutates inputs, keeps those that explore new execution paths, and reduces crashing inputs to smaller reproducible test cases.

Below are examples of two different fuzzing approaches. The first is robustness fuzzing, which checks whether the system remains stable when given unexpected or invalid input. The second is structured fuzzing, which checks correct behavior across valid but diverse inputs.

testImplementation 'com.code-intelligence:jazzer-junit:0.30.0'

...
    @FuzzTest
    void acceptsArbitrarySapResponse(@NotNull String source) {
        when(restTemplate.exchange(
                anyString(),
                eq(HttpMethod.POST),
                ArgumentMatchers.<HttpEntity<?>>any(),
                eq(String.class)))
                .thenReturn(ResponseEntity.ok(source));

        var year = String.valueOf(Year.now().getValue());

        var options = new Options();
        options.setFilter(Map.of(
                "yearFrom", year,
                "yearTo", year));

        assertDoesNotThrow(() -> {
            for (DataFetcher.Result ignored : fetcher.fetch(options)) {
                // Parsing occurs while the lazy iterator is consumed.
            }
        });
    }

    @FuzzTest
    void processesValidSapResponse(
            @InRange(min = 0, max = 99999999999L) long code,
            @InRange(min = 2016, max = 2100) int year,
            @NotNull @WithUtf8Length(min = 1, max = 32) String status,
            @NotNull @WithUtf8Length(min = 1, max = 64) String supplier,
            boolean hasPurchasingInfo,
            boolean fixedVendor,
            boolean deleted,
            boolean hasDocument,
            boolean mainComponents) throws JsonProcessingException {
        var purchasingInfo = hasPurchasingInfo
                ? List.of(Map.of(
                        "Fixed_Vendor", fixedVendor ? "X" : "",
                        "Vendor_code", supplier,
                        "Deletion_flag", deleted ? "X" : ""))
                : List.of();

        var documentPlacement = hasDocument
                ? List.of(Map.of(
                        "Component_descr", mainComponents ? "Components MAIN" : "Components",
                        "Supplier", supplier))
                : List.of();

        var source = objectMapper.writeValueAsString(Map.of(
                "records", List.of(Map.of(
                        "Code", code,
                        "Creation_date", year + "0408",
                        "Item_attributes", Map.of(
                                "Year", year,
                                "Code_status", status,
                                "Collection", "fuzz",
                                "Style_name", "fuzz"),
                        "Code_Purchasing_inforecords", purchasingInfo,
                        "Document_placement", documentPlacement))));

        when(restTemplate.exchange(
                anyString(),
                eq(HttpMethod.POST),
                ArgumentMatchers.<HttpEntity<?>>any(),
                eq(String.class)))
                .thenReturn(ResponseEntity.ok(source));

        var options = new Options();
        options.setFilter(Map.of(
                "yearFrom", String.valueOf(year),
                "yearTo", String.valueOf(year)));

        assertDoesNotThrow(() -> {
            for (DataFetcher.Result ignored : fetcher.fetch(options)) {
                // Parsing occurs while the lazy iterator is consumed.
            }
        });
    }
...

Jazzer executed 21,128 iterations, increased coverage from 119 to 124, expanded the corpus to 6 interesting inputs, and found no crashes or test invariant violations.

INFO: found LLVMFuzzerCustomMutator (0x106308c20). Disabling -len_control by default.
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 3483268244
INFO: Loaded 1 modules   (512 inline 8-bit counters): 512 [0x7667580000, 0x7667580200),
INFO: Loaded 1 PC tables (512 PCs): 512 [0x101362c40,0x101364c40),
INFO:        5 files found in /projects/app/.cifuzz-corpus/eu.example.ewc.app.sap.integration.fetcher.FetcherFuzzTest/processesValidResponse
INFO:        0 files found in /projects/app/build/resources/test/eu/example/sap/integration/fetcher/FetcherFuzzTestInputs/processesValidSapResponse
INFO:        1 files found in /var/folders/ds/frn5f9c14xl7dpq1m6_6v6yh0000gn/T/jazzer-java-seeds17930424486477809374
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
INFO: seed corpus: files: 6 min: 23b max: 27b total: 157b rss: 760Mb
#7      INITED cov: 119 ft: 119 corp: 3/77b exec/s: 0 rss: 760Mb
#18     REDUCE cov: 119 ft: 119 corp: 3/76b lim: 4096 exec/s: 0 rss: 760Mb L: 26/27 MS: 1 CustomCrossOver-
#19     REDUCE cov: 119 ft: 119 corp: 3/75b lim: 4096 exec/s: 0 rss: 760Mb L: 26/26 MS: 1 Custom-
#22     REDUCE cov: 122 ft: 122 corp: 4/101b lim: 4096 exec/s: 0 rss: 760Mb L: 26/26 MS: 3 CustomCrossOver-Custom-Custom-
#45     REDUCE cov: 123 ft: 123 corp: 5/127b lim: 4096 exec/s: 0 rss: 760Mb L: 26/26 MS: 3 CustomCrossOver-CustomCrossOver-CustomCrossOver-
#54     NEW    cov: 124 ft: 124 corp: 6/153b lim: 4096 exec/s: 0 rss: 760Mb L: 26/26 MS: 5 Custom-CustomCrossOver-ShuffleBytes-Custom-CustomCrossOver-
#4096   pulse  cov: 124 ft: 124 corp: 6/153b lim: 4096 exec/s: 2048 rss: 760Mb
#8192   pulse  cov: 124 ft: 124 corp: 6/153b lim: 4096 exec/s: 1170 rss: 760Mb
#16384  pulse  cov: 124 ft: 124 corp: 6/153b lim: 4096 exec/s: 496 rss: 760Mb
#21128  DONE   cov: 124 ft: 124 corp: 6/153b lim: 4096 exec/s: 346 rss: 760Mb
Done 21128 runs in 61 second(s)

> Task :app:test
Test results: SUCCESS (3 tests, 3 successes, 0 failures, 0 skipped)

ArchUnit as a Guardrail for AI-Generated Code

l3o6 — Mon, 14 Sep 2026 12:41:44 +0000

Agent-Based Code Generation and Architectural Drift

Today, an AI agent can quickly generate a significant amount of code: add new endpoints, services, or repositories. At the same time, it does not necessarily follow the project's architecture. It often favors local optimization, creates arbitrary abstractions, avoids importing ready-made solutions in favor of its own implementations, and suffers from verbosity. Therefore, the problem of defining architectural boundaries is acute. Tests, and evals in a broader sense, are responsible for enforcing certain rules so that a controller does not start accessing a repository directly, a service does not receive a dependency on a controller, and a repository does not depend on upper layers. This reduces the risk of unnoticed architectural drift and makes automated code generation more effective over a longer horizon.

What Is ArchUnit

ArchUnit is a library for testing the architecture of Java code. It analyzes bytecode and allows rules to be described for packages, classes, annotations, and dependencies between them. Such rules are represented as ordinary automated tests, which makes it possible to stop a build when the architecture is violated.

What Checks Can Be Performed

ArchUnit makes it possible to control, in particular:

dependencies between layers and the direction of those dependencies;
prohibiting controllers from accessing repositories;
prohibiting service dependencies on controllers;
prohibiting repository dependencies on services and controllers;
placing classes in packages based on name, annotation, or inheritance;
the presence and use of annotations (@Controller, @Service, @Repository);
class and package naming rules;
prohibiting cyclic dependencies between packages;
the visibility of classes, methods, and fields;
dependencies between modules and restrictions on external libraries;
the placement of tests and production classes;
inheritance, interface implementation, and calls to specific types.

Some architectural rules are worth implementing as a hidden test suite: they run in CI but are not exposed to the AI agent or included in its working context. These checks verify that a change genuinely follows the project’s architectural principles rather than merely adapting to rules the agent already knows about. The hidden suite should complement the explicit rules that describe the expected project structure.

Example in a Project

├── Application.java
├── controller
├── model
├── monitoring
├── repository
├── service
├── utils
└── validation

A dependency is added to the module's build.gradle:

testImplementation 'com.tngtech.archunit:archunit-junit5:1.5.0'

The test combines restrictions on dependencies between layers with repository naming rules, a prohibition on Spring Web in services, and a project requirement for SAP processors: all DataProcessor implementations must inherit from StandardProcessor. The last check is shown both as a standard ArchUnit rule and through a custom ArchCondition.

@AnalyzeClasses(packages = "org.foo.bar")
class ArchitectureTest {

    @ArchTest
    static final ArchRule controllersDoNotAccessRepositories = noClasses()
            .that().resideInAnyPackage("..controller..")
            .should().dependOnClassesThat().resideInAnyPackage("..repository..");

    @ArchTest
    static final ArchRule servicesDoNotAccessControllers = noClasses()
            .that().resideInAnyPackage("..service..")
            .should().dependOnClassesThat()
            .resideInAnyPackage("..controller..");

    @ArchTest
    static final ArchRule repositoriesDoNotAccessUpperLayers = noClasses()
            .that().resideInAnyPackage("..repository..")
            .should().dependOnClassesThat()
            .resideInAnyPackage("..controller..", "..service..");


    @ArchTest
    static final ArchRule repositoryInterfacesUseRepositorySuffix =
        classes()
                .that().areInterfaces()
                .and().resideInAPackage("..repository..")
                .should().haveSimpleNameEndingWith("Repository");

    @ArchTest
    static final ArchRule servicesDoNotUseSpringWeb =
        noClasses()
                .that().resideInAPackage("..service..")
                .should().dependOnClassesThat()
                .resideInAnyPackage("org.springframework.web..");


    @ArchTest
    static final ArchRule sapProcessorsUseTheStandardProcessingPipeline = classes()
            .that()
            .resideInAPackage("..sap.integration..")
            .and()
            .implement(DataProcessor.class)
            .should()
            .beAssignableTo(StandardProcessor.class);

    // Custom condition to check if a class implements DataProcessor but does not extend StandardProcessor.
    // It allows you to provide a more descriptive error message when the rule is violated.

    private static final ArchCondition<JavaClass> customCondition = new ArchCondition<>("extend StandardProcessor") {
        @Override
        public void check(JavaClass processor, ConditionEvents events) {
            if (processor.isAssignableTo(StandardProcessor.class)) return;

            var message = "%s implements DataProcessor but does not extend StandardProcessor"
                .formatted(processor.getFullName());
            var event = SimpleConditionEvent.violated(processor, message);

            events.add(event);
        }
    };

    @ArchTest
    static final ArchRule dataProcessorsExtendStandardProcessors = classes()
            .that().resideInAPackage("..sap.integration..")
            .and().implement(DataProcessor.class)
            .should(customCondition);

}

Conclusion

ArchUnit, of course, does not completely eliminate the need for review and business logic testing, but it reliably protects agreements about the project's structure. A small set of rules is especially useful in teams where code is created or modified by AI agents: CI can immediately identify architectural violations. ArchUnit provides additional and almost unlimited flexibility through the ability to create custom conditions and rules, making it possible to adapt checks to the specific requirements of a project.

Using Temporal SDK in Haskell

l3o6 — Sun, 13 Sep 2026 07:04:58 +0000

What Is Temporal

Temporal is a server that enables reliable execution and management of distributed, multi-step processes that unfold over time.
For example:

a user has paid for an order;
inventory must be reserved;
if the warehouse service is temporarily unavailable, the request must be retried;
if the item is unavailable, a replacement must be offered;
if payment has not yet arrived, wait for a signal. A conventional program can lose process state when it crashes, the server restarts, or a network failure occurs. Temporal persists the state and resumes execution from the appropriate point. It provides a CLI and web UI for managing, monitoring, and visualizing processes. It is an open-source alternative to systems such as AWS Step Functions, Azure Durable Functions, and others.

Installing and Running Temporal Locally

For example, using Nix, Docker, or Brew.

$ brew install temporal
$ temporal server start-dev
Temporal CLI 1.8.3 (Server 1.31.2, UI 2.50.1)

Temporal Server:      localhost:7233
Temporal Persistence: in-memory
Temporal UI:          http://localhost:8233
Temporal Metrics:     http://localhost:54946/metrics

Temporal SDK and langchain-hs

The example is implemented with the unofficial Temporal Haskell SDK. The project is described as being under active development, but it already supports implementing basic scenarios. The API may change in the future.
All Temporal SDKs, including the Haskell SDK, use a bridge written in Rust under the hood.

https://github.com/mercury/hs-temporal-sdk

The langchain-hs library is used to demonstrate a fulfillment agent. This is also a young project under active development.

https://github.com/tusharad/langchain-hs

Both packages are cloned locally and connected through Cabal to access the latest changes.

Core Temporal Components and Their Representation in the Haskell SDK

The full example code is available at https://github.com/lbobylev/hs-temporal-sdk-demo

Workflow

The Workflow is central: it describes the business logic of a process. It can consist of several Activities that run in a defined sequence and can be distributed over time.
In this case, it is a fragment of a hypothetical purchase-payment process.
It is deliberately simplified. The Workflow waits for an external CLI signal indicating that payment has been received, then reserves the product and offers the user a fulfillment option.

waitForPayment :: (RequireCallStack) => Int -> Workflow FulfillmentProposal
waitForPayment orderNumber = do
    -- Create a state variable to store the payment amount
    paymentAmount <- newStateVar Nothing

    -- Set up a signal handler that is called when the payment-confirmation signal is received
    setSignalHandler paymentConfirmed $ \amount ->
        writeStateVar paymentAmount (Just amount)

    -- Wait until the state variable is updated by the signal
    waitCondition $ do
        received <- readStateVar paymentAmount
        return $ received /= Nothing

    amount <- readStateVar paymentAmount
    case amount of
        Nothing -> error "payment amount is missing"
        Just _ -> do
            -- Helper function for extending activity start parameters
            -- Set a timeout for a single attempt
            let opts = defaultStartActivityOptions . StartToClose . seconds

            -- After receiving the payment-confirmation signal, attempt to reserve the product
            reservationResult <- executeActivity reserveProductActivity (opts 5) orderNumber

            -- Depending on the reservation result, offer the user a fulfillment option
            fulfillmentProposal <- executeActivity fulfillmentAgentActivity (opts 60) reservationResult

            return fulfillmentProposal

-- Create a workflow provider
paymentWorkflow = provideWorkflow JSON "payment-workflow" waitForPayment

Activity

An Activity is a separate unit of work that runs within a Workflow.
In this example, the first product-reservation attempt intentionally fails to demonstrate Activity retries according to the retry policy. StartToClose limits the duration of each individual attempt.
The final result also deliberately fails to trigger the fulfillment agent, which simulates offering the user an alternative fulfillment option.

reserveProduct :: Int -> Activity () ReservationResult
reserveProduct orderNumber = do
    -- Get the current attempt number
    info <- askActivityInfo
    let attempt = Activity.attempt info

    liftIO $
        putStrLn
            ( "Reserving product for order "
                <> show orderNumber
                <> ", attempt "
                <> show attempt
            )

    liftIO $
        if attempt == 1
            then ioError $ userError "temporary warehouse error"
            else putStrLn "Reservation completed"

    -- Return an unsuccessful reservation result
    return $ ReservationResult ReservationFailed (Just WarehouseUnavailable)

-- Create an activity provider
reserveProductActivity = provideActivity JSON "reserve-product" reserveProduct

After the reservation error is received, the fulfillment agent is called and simulates offering the user an alternative fulfillment option.
In this case, it is a stub for a real tool that would return a list of fulfillment options. In a real application, this would be a call to an external service.
The agent is implemented using the langchain-hs ReAct agent.

fulfillmentOptionsTool :: (Monad m) => Tool m
fulfillmentOptionsTool =
    createTool
        "fulfillment_options"
        "Provides fulfillment options based on reservation result"
        ( object
            [ "type" .= ("object" :: Text)
            , "properties" .= object []
            ]
        )
        runFulfillmentOptionsTool

runFulfillmentOptionsTool :: (Monad m) => Value -> m (Either LangchainError Text)
runFulfillmentOptionsTool _ =
    return . Right . pack . show $
        [ ShipFromWarehouse "Warehouse B"
        , OfferSubstitution 1234
        , WaitForRestock 5
        ]

fulfillmentAgent :: ReservationResult -> Activity () FulfillmentProposal
fulfillmentAgent reservation = do
    -- Depending on the reservation result, either return a successful result or call the fulfillment agent to obtain alternative fulfillment options
    if status reservation == Reserved
        then return $ FulfillmentProposal Nothing [] "Product reserved successfully"
        else do

            -- Start the langchain-hs ReAct agent

            apiKey <- liftIO $ pack <$> getEnv "OPENAI_API_KEY"
            let openai = newOpenAI apiKey "gpt-4o-mini"
                agent = createReActAgent openai [fulfillmentOptionsTool]
                prompt =
                    [ systemMessage $
                        "You MUST call the fulfillment_options tool before answering. "
                            <> "Return ONLY valid JSON, with no Markdown, code fences, or explanation. "
                            <> "The response must be exactly one object with an \"opts\" field. "
                            <> "The \"opts\" field must be a JSON array. "
                            <> "Each option must use exactly one of these formats: "
                            <> "{\"tag\":\"ShipFromWarehouse\",\"contents\":\"Warehouse B\"}, "
                            <> "{\"tag\":\"OfferSubstitution\",\"contents\":1234}, "
                            <> "{\"tag\":\"WaitForRestock\",\"contents\":5}. "
                            <> "If there are no options, return {\"opts\":[]}."
                    , userMessage "The product reservation failed. Please provide fulfillment options."
                    ]
            result <- runExceptT $ runReActAgent agent prompt

            case result of
                Left err -> error $ "Error running fulfillment agent: " <> show err
                Right message -> do

                    -- Attempt to decode the agent response into the expected format

                    let decode = eitherDecodeStrict' . encodeUtf8 . extractMessageText
                        content = decode message :: Either String FulfillmentAgentResponse
                    case content of
                        Left e -> error $ "Error decoding fulfillment options: " <> e
                        Right response ->
                            return $
                                FulfillmentProposal
                                    (reason reservation)
                                    (opts response)
                                    "Product reservation failed"

-- Create an activity provider
fulfillmentAgentActivity = provideActivity JSON "fulfillment-agent" fulfillmentAgent

Starting a Workflow and Sending a Signal

For a more detailed explanation of how Temporal works, see the official documentation.
Define a task queue from which the worker will receive tasks from the Temporal server.
Next, create the payment-received signal.
Disable telemetry and logging.

-- Create a queue
taskQueue :: TaskQueue
taskQueue = TaskQueue "temporal-demo"

paymentConfirmed :: KnownSignal '[Int]
paymentConfirmed = KnownSignal "payment-confirmed" JSON

main :: IO ()
main = do
    bracketRuntime NoTelemetry $ \runtime ->
        runNoLoggingT $
            bracketClient runtime defaultClientConfig $ \client -> do

                let workerConfig = configure () (paymentWorkflow, reserveProductActivity, fulfillmentAgentActivity) $ do
                        setNamespace (Namespace "default")
                        setTaskQueue taskQueue

                worker <- startWorker client workerConfig

                waitWorker worker

After starting main in GHCi and running the start command in the terminal, a new workflow should appear in the Temporal UI in a state of waiting for a signal.

$ temporal workflow start \
  --type payment-workflow \     # workflow name
  --task-queue temporal-demo \  # queue name
  --workflow-id order-3 \       # execution identifier
  --input 1003                  # hypothetical order number
Running execution:
  WorkflowId  order-3
  RunId       01a091e9-a48f-7e6b-a6c4-dac2f476b5b2
  Type        payment-workflow
  Namespace   default
  TaskQueue   temporal-demo

Send the payment-confirmation signal:

$ temporal workflow signal \
  --workflow-id order-3 \       # workflow identifier
  --signal payment-confirmed \  # signal name
  --input 1000                  # payment amount
Signal workflow succeeded

The Haskell Temporal SDK is still under active development, but it is already usable for basic workflows with signals, activities, retries, and workers.

AI and the Erosion of Practice

l3o6 — Sat, 05 Sep 2026 09:51:23 +0000

If we look at the situation with AI through the framework of MacIntyre’s After Virtue (1981), where the main concepts can be explained simply as follows:

Practice - any complex and organized activity that people do together for the sake of the activity itself, not just for quick personal gain. Examples include chess, football, physics, painting, and music. A practice is different from basic skills such as laying bricks or digging holes.
External goods - things such as money, power, and prestige that can be gained through participation in a practice. These goods are limited and competitive, so gaining more of them often means someone else gets less.
Internal goods - things such as mastery, understanding, and beauty that can only be achieved through participation in a practice and are part of the practice itself. They can usually be fully recognized only by people who take part in that practice. Their achievement also benefits society more broadly. For example, no amount of money can buy the ability to play the violin beautifully or to deeply understand quantum physics.
Institution - doctors need hospitals, scientists need laboratories, and both need equipment, salaries, and organization. Practices and institutions cannot exist without each other, but there is always a tension between them. When an institution starts focusing mainly on profit, rankings, status, or other external goods, it can "corrupt" the practice.

Once these concepts are defined, we can ask the following question:

Will the use of artificial intelligence, and its ability to reproduce the results of practices - mainly in the interests of institutions and for the pursuit of external goods - lead to the erosion of the practices themselves? How will it be possible in the future to continue and develop a practice, and to achieve excellence within it, if fewer and fewer people are able to recognize and value its internal goods, or are willing to spend the time and effort needed to achieve them? Could this eventually lead to the erosion of the institutions themselves?

Is today’s LLM a participant in a practice, and can it achieve excellence?

Clearly not on its own, without a human. Current systems do not have a practical biography of their own. They do not become members of a community, accept its standards as binding, develop virtues, experience internal goods, or pursue those goods for their own sake. They simply optimize their outputs within a given system of training and interaction. Their ability to produce these outputs is based on the accumulated results of practices carried out by many generations of human beings.

Minimalistic OpenCode multi-agent configuration

l3o6 — Fri, 04 Sep 2026 17:09:29 +0000

A multi-agent architecture with an orchestrator makes it possible to route small, predictable work to the lite agent while leaving complex tasks to the more capable one. This saves tokens and avoids unnecessary use of the more powerful, more expensive agent while preserving quality. Let's keep things simple and implement a router with two worker subagents.

plan → route → lite / build

Note: The transition from plan to router is manual.
First, plan produces an implementation plan, which I review myself. Only then, when needed, I pass the finalized plan to router.

This means router is not a mandatory extra step for every task and does not spend resources re-interpreting the original request. It works with an already reviewed and structured plan and only decides how to route execution between lite and build.

Roles

plan — the main agent for task analysis, planning, and refining the approach. In the current configuration, it is also set as the default agent.
route — the initial router that classifies tasks and delegates them to an implementation agent.
lite — handles small, mechanical, low-risk changes.
build — handles complex or ambiguous tasks: architecture, several files or modules, unclear debugging, security, APIs, migrations, performance, and other significant regression risks.

route chooses lite when a task is all of the following: local and well-defined, obvious from existing patterns, does not require an architectural decision, and has a low risk of side effects.
Otherwise, route must choose build. In particular, this applies when a task affects several components, requires
research or design, involves concurrency, security, persistence, or performance, or allows several substantially different interpretations. If the choice is unclear, route chooses build.

Agent Configuration Examples

# ls -al

├── agents
│   ├── lite.md
│   └── route.md
├── AGENTS.md
├── opencode.jsonc

A opencode.jsonc fragment connects the roles to their default settings:

{
  "default_agent": "plan",
  "agent": {
    "plan": {
        "model": "openai/gpt-5.6-terra"
    },
    "build": {
      "mode": "subagent",
      "model": "openai/gpt-5.6-terra"
    }
  }
}

`agents/route.md`

The frontmatter sets the description, the primary role, and the agent model. In permissions, the delegation rule is narrowed to the subagents, while editing and shell access are denied.

---
description: "Routes tasks to the appropriate implementation agent"
mode: primary
model: openai/gpt-5.6-terra 
permissions:
  - action: subagent
    resource: "*"
    effect: deny

  - action: subagent
    resource: Build
    effect: allow

  - action: subagent
    resource: Lite
    effect: allow

  - action: edit
    resource: "*"
    effect: deny

  - action: shell
    resource: "*"
    effect: deny
---

You are a task orchestrator.

Planning is complete. Treat the latest plan as approved: do not refine or rewrite it. Immediately choose the appropriate executor, `lite` or `build`, and delegate the implementation.

Do not perform tasks yourself. Classify and delegate them.

Use `lite` for tasks that are:

* simple
* clear
* localized
* low-risk
* mechanical or predictable

Use `build` for tasks that are:

* complex or ambiguous
* broad in scope
* high-risk
* require research, judgment, or planning
* have significant side effects

When uncertain, use `build`.

## Coding tasks

Treat a coding task as `build` if it involves any of the following:
* multiple files, modules, or services
* architecture or design decisions
* unclear root cause or substantial debugging
* unfamiliar code or missing context
* non-trivial refactoring
* APIs or public interfaces
* databases, persistence, or migrations
* concurrency or asynchronous behavior
* authentication, permissions, or security
* performance or resource usage
* dependency or infrastructure changes
* significant regression risk
* several valid implementation approaches requiring judgment

Use `lite` only when the coding change is local, obvious from existing patterns, and unlikely to affect unrelated behavior.

Delegate one clear task to the appropriate agent.
After completion, verify the result and return a concise response.

`agents/lite.md`

The frontmatter sets a limit of 12 steps. The only permissions rule prohibits further delegation.

---
description: Handles small, mechanical, low-risk tasks
mode: subagent
model: openai/gpt-5.6-luna
steps: 12
permissions:
  - action: subagent
    resource: "*"
    effect: deny
---

Handle small, well-defined tasks.

Prefer the simplest solution.
Follow existing patterns and constraints.
Avoid unnecessary changes or extra work.

Before acting:

* inspect the relevant context
* identify the expected pattern
* make the smallest consistent change

Afterwards:

* verify the result when possible
* report what changed

If the task requires substantial research, judgment, planning, or broad changes, stop and report that it should be handled by `build`.

Setting Up Haskell Development in Neovim

l3o6 — Fri, 28 Aug 2026 17:43:25 +0000

It is assumed that Neovim, lazy.nvim, and Telescope are already configured.

Install Haskell tools

curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh

ghcup install ghc
ghcup set ghc recommended
ghcup install cabal
ghcup install hls
ghcup install stack

Restart your shell, then install Hoogle and generate the local Hoogle database:

cabal update
cabal install hoogle
hoogle generate

Verify the installation:

ghc --version
cabal --version
haskell-language-server-wrapper --version
hoogle --version

haskell-tools.nvim uses haskell-language-server-wrapper for LSP and the local Hoogle database generated by the hoogle generate command.

Configuring Haskell IDE Support

HLS (Haskell Language Server) provides editor features such as diagnostics, type information, import resolution, and go-to-definition. It uses hie-bios, a build-configuration layer originally developed for HIE (Haskell IDE Engine), to determine how each source file should be compiled. The hie.yaml file tells hie-bios whether the project uses Stack or Cabal and maps source directories to their build components. This is especially important in multi-package repositories, where files may use different dependencies or compiler options. With the correct configuration, HLS can load each file in the same context used by the project's build tool.

In your root Haskell project directory, run:

stack build

# install generator
stack install implicit-hie

# generate configuration
gen-hie --stack > hie.yaml

Configure `haskell-tools.nvim`

{
    "mrcjkb/haskell-tools.nvim",
    version = "^10",
    lazy = false,
    init = function()
        vim.g.haskell_tools = {
            tools = {
                hoogle = {
                    mode = "telescope-local",
                },
                repl = {
                    handler = "builtin",
                },
                hover = {
                    auto_focus = true,
                },
            },
        }
    end,
}

haskell-tools.nvim starts HLS by itself. Do not configure HLS separately through nvim-lspconfig or Mason.

haskell-tools.nvim currently requires Neovim 0.12 or later. If you use Neovim 0.11 or an earlier release, install a compatible older version of the plugin instead. The version = "^10" constraint should only be used after confirming that version 10 supports your Neovim version.

Optional Telescope Haskell Tools extension

After configuring Telescope, load the ht extension:

telescope.setup(...)
telescope.load_extension("ht")

It provides Telescope search commands for the current Haskell package:

:Telescope ht package_files
:Telescope ht package_grep

Add Treesitter support for Haskell

Add Haskell to your existing Tree-sitter configuration:

return {
    {
        "nvim-treesitter/nvim-treesitter",
        -- ...
        config = function()
            local ts = require("nvim-treesitter")
            ts.setup()
            ts.install({
                -- other languages...
                "haskell",
                "haskell_persistent",
            })

            -- configure indentation for Haskell filetypes
            vim.api.nvim_create_autocmd("FileType", {
                pattern = {
                    -- other filetypes...
                    "haskell",
                },
                callback = function()
                    pcall(vim.treesitter.start)
                end,
            })

            -- rest of your config...
        end,
        -- rest of your plugin spec...
    },
}

Add Haskell key mappings

The mappings are buffer-local and only apply to Haskell files.

-- ftplugin/haskell.lua

local ht = require("haskell-tools")

local map = function(mode, key, action, desc)
    vim.keymap.set(mode, key, action, {
        noremap = true,
        silent = true,
        buffer = 0,
        desc = desc,
    })
end

local toggle_file_repl = function()
    ht.repl.toggle(vim.api.nvim_buf_get_name(0))
end

map("n", "gd", vim.lsp.buf.definition, "Go to definition")
map("n", "gr", vim.lsp.buf.references, "Find references")
map("n", "<leader>lh", "<cmd>Haskell hover<CR>", "Hover actions")
map("n", "<leader>hs", ht.hoogle.hoogle_signature, "Hoogle signature")
map("n", "<leader>hc", vim.lsp.codelens.run, "Run CodeLens")
map("n", "<leader>he", ht.lsp.buf_eval_all, "Evaluate snippets")
map("n", "<leader>hp", ht.repl.toggle, "Toggle project REPL")
map("n", "<leader>hf", toggle_file_repl, "Toggle file REPL")
map("n", "<leader>hq", ht.repl.quit, "Quit REPL")

Debugging

Install DAP

ghci-dap must be built with the same GHC version used by the project. Otherwise GHC cannot load the project’s interface files and fails with mismatched interface file versions. Verify compatibility before debugging with ghci-dap --version, and use the binary built by the project’s selected build tool and GHC version.

# cabal
cabal install ghci-dap haskell-debug-adapter

# stack, run from the project root
stack install haskell-dap ghci-dap haskell-debug-adapter

haskell-debug-adapter --version
ghci-dap --version

haskell-debug-adapter 0.0.42.0 may fail to build with hie-bios 0.20 or later because of an API incompatibility. If Cabal reports a TargetWithContext type error, constrain hie-bios:
cabal install ghci-dap haskell-debug-adapter \
  --constraint='hie-bios < 0.20'

Plugins configuration

-- lua/plugins/dap.lua
return {
    {
        "mfussenegger/nvim-dap",
        cmd = { "DapContinue", "DapToggleBreakpoint", "DapStepInto"   },
    },
    {
        "rcarriga/nvim-dap-ui",
        ft = { "haskell" },
        dependencies = { "mfussenegger/nvim-dap", 'nvim-neotest/nvim-nio' },
        config = function()
            local function map(lhs, rhs, desc)
                vim.keymap.set("n", lhs, rhs, { noremap = true, silent = true, desc = desc })
            end

            local dap = require 'dap'
            local dapui = require 'dapui'
            local widgets = require 'dap.ui.widgets'

            dapui.setup {
                layouts = {
                    {
                        elements = {
                            -- { id = "repl",        size = 0.30 },
                            { id = "scopes",      size = 0.25 },
                            { id = "breakpoints", size = 0.25 },
                            { id = "stacks",      size = 0.25 },
                            { id = "watches",     size = 0.25 },
                        },
                        position = "right",
                        size = 50
                    },
                    {
                        elements = {
                            { id = "repl", size = 1 }
                        },
                        position = "bottom",
                        size = 20
                    },
                    {
                        elements = {
                            { id = "console", size = 1 }
                        },
                        position = "bottom",
                        size = 25
                    },
                },
            }

            dap.listeners.before.attach.dapui_config = function()
                dapui.open()
            end
            dap.listeners.before.launch.dapui_config = function()
                dapui.open()
            end
            dap.listeners.before.event_terminated.dapui_config = function()
                -- dapui.close()
            end
            dap.listeners.before.event_exited.dapui_config = function()
                -- dapui.close()
            end

            local set_conditional_breakpoint = function()
                dap.set_breakpoint(vim.fn.input('Breakpoint condition: '))
            end

            local set_log_point = function()
                dap.set_breakpoint(nil, nil, vim.fn.input('Log point message: '))
            end

            map('<leader>du', function() dapui.toggle { reset = true } end, 'Toggle dap ui')
            map('<leader>dU', function() dapui.toggle { reset = true, layout = 1 } end, 'Toggle dap ui')
            map("<leader>db", dap.toggle_breakpoint, "Set breakpoint")
            map("<leader>dB", set_conditional_breakpoint, "Set conditional breakpoint")
            map("<leader>dL", set_log_point, "Set log point")
            map('<leader>dC', dap.clear_breakpoints, "Clear breakpoints")
            map("<leader>dc", dap.continue, "Continue")
            map("<leader>dn", dap.step_over, "Step over")
            map("<leader>di", dap.step_into, "Step into")
            map("<leader>do", dap.step_out, "Step out")
            map('<leader>dd', dap.disconnect, "Disconnect")
            map('<leader>dt', dap.terminate, "Terminate")
            map("<leader>dr", dap.repl.toggle, "Open REPL")
            map("<leader>dl", dap.run_last, "Run last")
            map('<leader>dv', widgets.hover, "Variables")
            map('<leader>ds', function() widgets.centered_float(widgets.scopes) end, "Scopes")
        end
    },
}

haskell-tools.nvim automatically discovers haskell-debug-adapter launch configurations from Cabal and Stack projects when nvim-dap is installed and haskell-debug-adapter is executable in PATH. No manual dap.adapters.ghc configuration is required.

Formatting

Install formatters

cabal install fourmolu stylish-haskell
fourmolu --version
stylish-haskell --version

{
    "stevearc/conform.nvim",
    opts = {
        formatters_by_ft = {
            -- Other formatters
            haskell = { "stylish_haskell", "fourmolu" },
        },
    },
    -- Rest of the configuration
}

stylish_haskell runs first to organize imports; fourmolu then formats the complete Haskell source file.

Install and verify

:Lazy sync
:TSInstall haskell haskell_persistent
:checkhealth haskell-tools

Hover actions

File REPL

Running Pi Coding Agent for Java Development in Docker Sandbox

l3o6 — Mon, 10 Aug 2026 12:51:58 +0000

Docker Sandboxes provide isolated microVM environments for AI coding agents. Every sandbox has its own Docker daemon, filesystem, and network, so an agent can build containers, install packages, run development tools, and modify files inside an isolated environment.

Pi is a minimal terminal coding harness with support for TypeScript extensions, skills, prompt templates, themes, and packages.

This setup is intended specifically for Java development. It combines Pi with Docker Sandboxes and adds a reusable Java development environment.

Docker Sandboxes currently do not include a ready-made Pi template, so we can create one.

Install Docker Sandboxes

Install sbx with Homebrew and authenticate:

brew install docker/tap/sbx
sbx login

Add MCP secrets

Store both API keys as Docker Sandbox secrets:

sbx secret set-custom -g \
  --host mcp.tavily.com \
  --env TAVILY_API_KEY \
  --value "<YOUR_TAVILY_API_KEY>"

sbx secret set-custom -g \
  --host mcp.context7.com \
  --env CONTEXT7_API_KEY \
  --value "<YOUR_CONTEXT7_API_KEY>"

Pi authentication is handled separately through the browser using a Codex subscription, so there is no OpenAI API key in this setup, but it can be easily added as a secret.

Create the Dockerfile

In short, the sandbox will include:

Java 21
Gradle 8.5
SDKMAN
Pi Coding Agent
OpenSpec
Playwright
MCP support for Pi
Context7
grep.app
Tavily
common command-line utilities required by the development toolchain

This gives Pi a complete Java development environment together with documentation search, source-code search, web research, browser automation, and MCP integration out of the box.

FROM docker/sandbox-templates:shell

USER root

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        curl \
        unzip \
        zip \
        ca-certificates \
    && rm -rf /var/lib/apt/lists/*

RUN npm install -g --ignore-scripts \
    @earendil-works/pi-coding-agent

ENV SDKMAN_DIR=/root/.sdkman

RUN curl -fsSL https://get.sdkman.io | bash \
    && bash -c '\
        source /root/.sdkman/bin/sdkman-init.sh && \
        sdk install java 21.0.10-tem && \
        sdk install gradle 8.5 \
    '

ENV JAVA_HOME=/root/.sdkman/candidates/java/current
ENV GRADLE_HOME=/root/.sdkman/candidates/gradle/current
ENV PATH="${JAVA_HOME}/bin:${GRADLE_HOME}/bin:${PATH}"

RUN npm install -g \
    @fission-ai/openspec@latest \
    @playwright/cli@latest

RUN npx playwright install-deps

USER agent
WORKDIR /home/agent

RUN pi install npm:pi-mcp-adapter

RUN mkdir -p /home/agent/.config/mcp

COPY --chown=agent:agent mcp.json /home/agent/.config/mcp/mcp.json

Configure MCP servers

Create mcp.json next to the Dockerfile:

{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "${CONTEXT7_API_KEY}"
      }
    },
    "gh_grep": {
      "url": "https://mcp.grep.app"
    },
    "tavily": {
      "url": "https://mcp.tavily.com/mcp",
      "headers": {
        "Authorization": "Bearer ${TAVILY_API_KEY}"
      }
    }
  }
}

The configuration gives Pi access to three MCP services:

Context7 for Java library, framework, and API documentation
grep.app for searching public source code and Java implementation examples
Tavily for web search and research

The credentials are injected through the sandbox secrets configured earlier.

Build and publish the sandbox template

Build the image and push it to a registry:

docker build -t <your-login>/pi-template --push .

Create the sandbox

Create a named sandbox from the new template and start Pi:

sbx run --name pi --template <your-login>/pi-template shell -- -c pi

The sandbox now has a persistent Java development environment based on the custom image.

Inside Pi, complete the browser-based Codex authentication flow when prompted.

Sandbox persistence

The project directory is mounted from the host, so source code changes survive sandbox recreation. Sandbox-local state (Pi configuration, caches, and manually installed tools) exists only inside the sandbox unless explicitly persisted. Keep important project data in the mounted repository and use the Docker image for reproducible tooling.

Network access control

For a more restrictive setup, you can configure the sandbox with networking: deny all. This blocks all outbound connections by default.

Then allow only the hosts required for the agent workflow using a whitelist:

sbx policy init deny-all
sbx policy allow network "api.tavily.com,grep.app,mcp.context7.com,api.openai.com,auth.openai.com,chatgpt.com"

Start Pi again later

After the sandbox has been created, launch Pi with:

sbx run --name pi shell -- -c pi

The --template argument is only needed when creating the sandbox from the custom template.

Result

Pi can inspect and modify Java projects, run Gradle builds and tests, install additional tooling, use Docker, execute browser-based workflows, and access the configured MCP servers.

Java 21 and Gradle are available out of the box, while SDKMAN makes it straightforward to switch to another Java or Gradle version when a project requires a different toolchain.

The host system remains outside the agent's working environment, while the sandbox can be reused across future Java coding sessions.

Run Big MoE Models on a 16GB Mac with Flash-MoE

l3o6 — Sun, 09 Aug 2026 18:05:25 +0000

anemll-flash-llama.cpp is useful for running large MoE models on Macs with limited RAM. Instead of keeping all experts in unified memory, it stores them on SSD and loads only the experts needed for the current tokens into a small cache (slot-bank). This makes models that normally would not fit in memory usable on much smaller machines, trading some speed for dramatically lower RAM requirements.

Benchmark of Qwen3.5-35B-A3B using the anemll-flash-llama.cpp Flash-MoE / slot-bank backend on a MacBook Pro with Apple M1 Pro and 16 GB unified memory.

Test Environment

Item	Configuration
Hardware	MacBook Pro
SoC	Apple M1 Pro
Unified Memory	16 GB
Metal Working Set Limit	~12.7 GB
Backend	Metal + Flash-MoE
Flash-MoE Mode	`slot-bank`
GPU Layers	999
Top-K Override	4
Prefill Batch	8192
Cache I/O Split	4
Async Upload	Off
Parallel Reads	Off

Models

Model	Quantization	GGUF Size
Qwen3.5-35B-A3B-Q3_K_M	Q3_K_M	~16 GB
Qwen3.5-35B-A3B-UD-Q4_K_XL	UD-Q4_K_XL	~22 GB

Both models are larger than the practical Metal working-set limit and therefore rely heavily on Flash-MoE expert streaming from storage.

Benchmark Results

Model	Size	Slot Bank	Prompt	Generation	Cache Hit	Expert I/O	Routed Time / Token
Q3_K_M	16 GB	4	3.6 t/s	5.1 t/s	31.0%	74.61 GiB	119.09 ms
Q3_K_M	16 GB	8	4.5 t/s	3.4 t/s	42.2%	62.53 GiB	192.23 ms
UD-Q4_K_XL	22 GB	4	4.3 t/s	4.5 t/s	30.3%	105.93 GiB	346.22 ms
UD-Q4_K_XL	22 GB	8	5.6 t/s	5.3 t/s	44.1%	84.97 GiB	307.75 ms

Detailed Flash-MoE Comparison

Metric	Q3 / Bank 4	Q3 / Bank 8	Q4 / Bank 4	Q4 / Bank 8
Slot-bank cache hit	31.0%	42.2%	30.3%	44.1%
Cache misses / call	2.76	2.31	2.79	2.24
Routed expert data	74.61 GiB	62.53 GiB	105.93 GiB	84.97 GiB
Expert source I/O time	60.33 s	98.77 s	181.54 s	161.74 s
Expert upload time	3.10 s	3.61 s	3.08 s	2.37 s
Routed MoE time	42.78 s	64.83 s	66.61 s	57.22 s
Routed time / token	119.09 ms	192.23 ms	346.22 ms	307.75 ms
Routed bytes / token	0.14 GiB	0.12 GiB	0.20 GiB	0.16 GiB
Prefetch hit rate	93.6%	97.9%	93.5%	98.0%
Expert evictions	~59k*	49,057	59,369	47,419

*Approximately, based on the per-run Flash-MoE statistics.

Key Findings

Q3_K_M is clearly the better fit for a 16 GB M1 Pro. It requires substantially less expert I/O than UD-Q4_K_XL and produces much lower routed-MoE latency.

The best result in this test is Q3_K_M with slot-bank=4, reaching only 119 ms/token of accumulated routed-MoE overhead. Despite its lower 31% expert-cache hit rate, it was considerably faster than the Q3 slot-bank=8 run.

Increasing the slot bank from 4 to 8 consistently improves caching. Cache hit rates increased from roughly 30–31% to 42–44%, while prefetch hit rates reached approximately 98%. It also reduced the amount of expert data read from storage.

For UD-Q4_K_XL, slot-bank=8 is clearly preferable to slot-bank=4: routed overhead dropped from 346 ms/token to 308 ms/token, expert traffic fell from 105.9 GiB to 85.0 GiB, and the cache hit rate improved from 30.3% to 44.1%.

However, the benchmark is overwhelmingly storage-I/O bound. Expert source I/O accounts for approximately 96–98.5% of Flash-MoE routed processing time. Metal upload overhead is comparatively small.

Conclusion

Category	Best Result
Best model for M1 Pro 16 GB	Q3_K_M
Lowest routed MoE latency	Q3_K_M / slot-bank 4
Highest expert cache hit	Q4_K_XL / slot-bank 8 — 44.1%
Highest prefetch hit	Q4_K_XL / slot-bank 8 — 98.0%
Lowest expert traffic	Q3_K_M / slot-bank 8 — 62.53 GiB
Best Q4 configuration	UD-Q4_K_XL / slot-bank 8

Overall, Qwen3.5-35B-A3B is technically usable on a 16 GB M1 Pro through Flash-MoE expert streaming, even when the GGUF itself is 16–22 GB. The Q3_K_M quantization is considerably more practical on this hardware.

The main performance bottleneck is not GPU compute or Metal upload but expert data being streamed from storage. As a result, SSD I/O behavior and Flash-MoE cache effectiveness have a very large impact on generation performance.

Building an Agentic Harness with Spring AI and LangGraph4j

l3o6 — Sat, 08 Aug 2026 07:23:36 +0000

There are many architectures for agentic systems, and Verified Multi-Agent Orchestration (VMAO) is one of them: an architecture that makes it possible to turn a natural-language request into a strict sequential execution plan. The system first decides what is worth investigating, splits the work into branches, executes independent parts in parallel, assembles the picture, and checks whether there is enough confidence for the final answer. If the picture is weak, the next loop receives the context of the previous attempt.
In this demo, the same flow is shown through an incident investigation scenario. A user comes with a symptom: checkout-service has an increase in 5xx responses, along with a time window, a possible dependency, and a suspicion of degradation. The harness first chooses the traces worth checking: metrics, logs, traces, deployment, config. From this, the work graph is formed.

A plain text list of steps does not always map well onto a runtime: it is hard to see which parts can run at the same time and which must run sequentially. A graph gives a stricter contract. Some branches start immediately, others wait for results. Data flows explicitly: metric results can go into period comparison, log results into signature detection, and terminal branches converge into a shared analysis.

Diagram

The demo scope is intentionally compressed. Synthetic data gives a repeatable scenario, and local agents remove integration noise. The mechanics themselves remain the main focus: the model proposes a plan, the runtime checks its shape, the graph executes independent branches, and the result passes through a quality gate. A production version would add real data sources, sandboxing, access controls, observability, and stronger verification. LangGraph4j was used to implement the graph: a Java clone of LangGraph that allows building graphs with asynchronous nodes and conditional transitions.
An important aspect is budget pressure at every level of execution. The system does not treat the reasoning loop as an unlimited resource: the overall budget spans planning, graph execution, sub-agent calls, verification, and replanning. Planning consumes model usage, execution limits the number of agent calls and wall-clock time, parallel branches compete for the same shared budget, and a new cycle is allowed only if enough resources remain for a useful refinement. In this way, orchestration continuously monitors how much additional work it can still afford.

The outer graph shows the whole cycle well:

return new StateGraph<>(Lg4jRunState.SCHEMA, Lg4jRunState::new)
        .addNode("plan", node_async(state -> planNode.plan(state, budget)))
        .addNode("validate", node_async(validateNode::validate))
        .addNode("execute", node_async(state -> executionNode.execute(state, budget)))
        .addNode("build_report", node_async(reportNode::build))
        .addNode("verify", node_async(verificationNode::verify))
        .addNode("decide_replan", node_async(state -> replanDecisionNode.decide(state, budget)))
        .addNode("finish", node_async(finishNode::finish))
        .addEdge(START, "plan")
        .addEdge("plan", "validate")
        .addEdge("validate", "execute")
        .addEdge("execute", "build_report")
        .addEdge("build_report", "verify")
        .addEdge("verify", "decide_replan")
        .addConditionalEdges("decide_replan",
                edge_async(state -> state.needsReplan() ? "replan" : "finish"),
                Map.of("replan", "plan", "finish", "finish"))
        .addEdge("finish", END);

The plan graph is executed using the classic Kahn’s algorithm together with lightweight virtual threads. Each node maintains a counter of unfinished dependencies. Nodes with no dependencies are immediately added to the ready queue. The executor starts as many tasks from this queue as allowed by maxConcurrency. Whenever a node completes, its result is added to the shared execution state, and the dependency counters of its downstream nodes are decremented. If a dependent node’s counter reaches zero, that node becomes ready to run.

var nodesById = Lg4jPlanDag.nodesById(plan);
var dependents = dependents(plan);
var remainingDeps = remainingDeps(plan);
var ready = readyNodes(plan, remainingDeps);

while (!ready.isEmpty() || running > 0) {
    while (running < maxConcurrency && !ready.isEmpty()) {
        var node = ready.remove();
        var state = execution.state();

        completions.submit(() -> new NodeUpdate(
                node.getId(),
                executeNode(budget, agentInvocationExecutor, node, state)));

        running++;
    }

    var completed = take(completions);
    running--;

    execution.apply(completed.update());

    for (var dependentId : dependents.getOrDefault(completed.nodeId(), List.of())) {
        if (remainingDeps.merge(dependentId, -1, Integer::sum) == 0) {
            ready.add(nodesById.get(dependentId));
        }
    }
}

execution.apply(analyzeEvidence(plan, budget, agentInvocationExecutor, execution.state()));

The scheduler handles fan-out and fan-in naturally: a completed node can unblock several downstream nodes, while a node with multiple dependencies waits for all of them. Independent branches run in parallel, limited by the max concurrency setting. Final evidence analysis starts only after all nodes have finished.

Result verification in the demo is intentionally simplified. In a real system, its depth would be much greater: for example, it would include analysis of intermediate results, contradiction checks, and so on. The architecture already has a dedicated place for it. If verification passes, the report is formed. If the report is weak, the new attempt receives the context of the previous one, and the next plan is built with that experience.

Ultimately, this is simply an attempt to show a VMAO-style process:

planning
validation
parallel execution of multiple sub-agents
evaluation and formation of either the result or a new signal

The value of the demo, in my view, is that this flow is visible without extra noise.

Repository: https://github.com/lbobylev/harness-demo

Inspired by: VERIFIED MULTI-AGENT ORCHESTRATION: A PLAN-
EXECUTE-VERIFY-REPLAN FRAMEWORK FOR COM-
PLEX QUERY RESOLUTION

Building an Agentic Harness with Spring AI

l3o6 — Fri, 07 Aug 2026 23:31:48 +0000

Demo Scenario

This harness uses a game recommendation agent as its working scenario. The user describes preferences: relaxed pacing, short sessions, story, tactical depth, low stress, budget, or favorite genres. The harness turns that goal into an executable plan, collects data from local tools, and returns a final recommendation.

The task is small, but it has all the properties of an agentic pipeline. The data lives in independent sources: genre facts, aggregated reviews, a game catalog, and prices. The get_genre_facts, get_genre_reviews, get_games, and get_prices nodes run in parallel. Their results then converge into summarizer_node, which receives the user's preferences and the collected data, then produces the final report through Spring AI.

From there, the scenario goes through one pipeline: planning, graph validation, parallel execution, verification, and final report assembly.

The scenario data lives in GameRecommendationData: Outer Wilds, Stardew Valley, Baldur's Gate 3, Civilization VI, Hades, genre facts, reviews, and fake prices. The local data layer makes the run reproducible and keeps the focus on the key parts of the harness: planner structured output, DAG validation, parallel execution, budget pressure, recovery decisions, trace events, and the final verification gate.

The whole run can be represented as one pipeline:

User Goal
   |
   v
Planner ---> Plan
   |
   v
Validator
   |
   v
DAG Scheduler ---> Tools
   |
   v
Verifier
   |
   v
FinalReport

Budget / Trace / Recovery run alongside the whole pipeline:
- Budget constrains planning and execution.
- Trace records events at every stage.
- Recovery sends a failed run back to the planner when replan is possible.

Model Call

All LLM calls in the harness go through Spring AI ChatClient. For the rest of the code, the model looks like a regular runtime component: it receives a system prompt, user input, and an expected response shape, then returns a structured result or text. This keeps orchestration separate from the details of a specific LLM API.

The model is currently used in two places. SpringAiPlanner receives the user's goal and the tool catalog, then returns a structured Plan through provider structured output. summarizer_node inside GameRecommendationTools receives already collected data and produces the final recommendation text. These roles are separated at the code level: the planner is responsible for the execution shape, while the summarizer is responsible for the user-facing answer.

The key point in the planner: the model returns a domain model Plan, not arbitrary text.

ResponseEntity<ChatResponse, Plan> response = chatClient.prompt()
        .system(SYSTEM_PROMPT)
        .user(userPrompt(request))
        .call()
        .responseEntity(Plan.class, spec -> spec.useProviderStructuredOutput().validateSchema());

Plan plan = response.entity();
AiUsage usage = usageExtractor.extract(response.response());
return new PlanningResult(plan, usage);

After every LLM call, the harness extracts usage metadata through AiUsageExtractor: model, input tokens, output tokens, and total tokens. That data goes into Budget, trace events, and the final RunResult. The LLM remains a pluggable runtime component, while validation, execution, budget, and verification continue to live around it as separate layers.

Tools

Tools in the harness are declared as regular Java methods with Spring AI @Tool and @ToolParam annotations. From these annotations, Spring AI builds tool definitions: name, description, and input schema. ToolCatalog turns them into one catalog read by the planner, validator, and orchestrator.

ToolCallbackProvider is a Spring AI interface for supplying tool callbacks. The harness uses the built-in MethodToolCallbackProvider: it takes an object with @Tool methods and turns those methods into ToolCallback instances available through getToolCallbacks().

public ToolCatalog(GameRecommendationTools tools) {
    this.callbackProvider = MethodToolCallbackProvider.builder()
            .toolObjects(tools)
            .build();
}

Each ToolCallback contains a ToolDefinition: tool name, description, and input schema. ToolCatalog extracts these definitions and turns them into a compact ToolDefinitionView understood by the harness.

public List<ToolDefinitionView> definitions() {
    return Arrays.stream(callbackProvider.getToolCallbacks())
            .map(ToolCallback::getToolDefinition)
            .map(definition -> new ToolDefinitionView(
                    definition.name(),
                    definition.description(),
                    definition.inputSchema(),
                    roleOf(definition.name())))
            .toList();
}

The catalog is used for more than the planner prompt. It becomes the source of truth for plan validation. DagValidator checks every node against real tool names, validates argument names, required parameters, and references to other node results. A wrong tool or argument name stops the run before the execution phase. ToolCatalog also assigns each tool a role, so the harness can distinguish data tools from the final synthesis node.

One important detail in this harness is explicit argument passing. deps define execution order, while arguments define data flow. LITERAL is used for values that the model extracts or formulates from the user request. NODE_RESULT is used for values that come from another node's result. The validator also checks that NODE_RESULT references an existing node and that this node is listed in deps.

This contract makes tools suitable for an agentic runtime. The planner sees real schemas, the scheduler receives already validated arguments, the budget counts every tool call, and the trace shows which tool ran, with what status and role: DATA or FINAL_SYNTHESIS.

Planner Graph

The planner returns the domain model Plan. Inside it is a set of PlanNode objects: each node contains an id, tool name, argument list, and dependencies in deps. This format turns the model response into an executable structure that can be validated before launch.

public class PlanNode {
    private String id;
    private String tool;
    private List<ArgumentBinding> arguments;
    private List<String> deps;
    private NodeStatus status = NodeStatus.PENDING;
    ...
}

deps describe the graph structure: which node must finish before another. arguments describe data flow: which values the model extracts from the user request and which values come from previous node results. The validator and scheduler use this separation to check execution order and data flow independently.

Before execution, DagValidator checks the plan as a structure. It indexes nodes by id, checks references in deps, verifies that tools exist in ToolCatalog, rejects cycles, checks required arguments, and requires exactly one FINAL_SYNTHESIS node. After this check, the scheduler receives a valid DAG.

Parallel Graph Execution

After validation, the plan goes to DagScheduler. It starts with root nodes that have no dependencies, then launches downstream nodes when their dependencies reach a terminal state. In the demo scenario, get_genre_facts, get_genre_reviews, get_games, and get_prices can start immediately, while summarizer_node starts after the required data nodes complete successfully.

The scheduler keeps runtime state in SchedulerState. It indexes nodes by id, builds a dependents map, counts remaining dependencies for each node, and separately tracks failed dependencies. This lets the graph move forward through node completion events: a completed node either opens the path for its children or closes it through a propagated skip.

In an event-driven scheduler, independent graph branches continue as their own dependencies become ready. If one data node finishes quickly, its downstream node can start immediately while other independent tool calls are still running.

Event-driven DAG scheduling

120 ms   facts   ───────────────> normalize_facts ───────┐
180 ms   games   ───────────────> filter_games ──────────┤
700 ms   prices  ───────────────> attach_prices ─────────┤
900 ms   reviews ───────────────> normalize_reviews ─────┘
                                                        │
                                                        v
                                                summarizer_node

Synchronization appears only where the graph itself requires it. In the example above, summarizer_node waits for all data branches, while intermediate steps inside each branch do not wait for neighboring branches to finish.

A compressed skeleton shows the core mechanics:

for (PlanNode node : state.initialReadyNodes()) {
    schedule(node);
}

state.awaitCompletion();

private void onNodeCompleted(NodeExecutionOutcome outcome) {
    for (PlanNode child : state.dependentsOf(outcome.node())) {
        if (state.dependencyCompleted(child, outcome.successful()) != 0) {
            continue;
        }

        if (state.hasFailedDependencies(child)) {
            skipNode(child, "dependency failed");
            continue;
        }

        schedule(child);
    }

    state.nodeTerminal();
}

Before starting a scheduled node, the scheduler charges one tool call against the budget. If the budget cannot start the call, the node is marked SKIPPED with reason budget exhausted, and that outcome is propagated to dependent nodes. If the tool completes successfully, the scheduler stores result and usage on the node, charges token and cost usage, marks the node DONE, and checks which dependent nodes are ready to start.

Failure stays attached to the node that produced it. ToolExecutionException preserves its HarnessErrorCode; other unexpected exceptions become TOOL_EXECUTION_FAILED. If a dependency fails or is skipped, downstream nodes that require it are marked SKIPPED with reason dependency failed.

Parallelism is capped by harness.execution.max-concurrency. Internally, DagScheduler uses a fixed thread pool, so fan-out stays bounded. The scheduler launches ready nodes, records node.start, node.finish, node.fail, and node.skip events, updates dependent state, and waits for the graph to finish.

Execution Context

Context in the harness lives in layers. Each layer appears at its own stage of the run and passes forward only the data needed by the next phase.

Request scope starts with RunRequest: the user goal and sessionId. goal becomes the main input for the planner, while sessionId flows through trace events and the final RunResult to link the run to an external session.

Planning attempt scope appears inside each planning attempt. The planner receives goal, the current tool catalog, and failureContext. On the first attempt, failureContext is empty. After a validation failure or execution failure, the orchestrator fills it with the failure description and starts a new planning attempt. The result of this phase is the generated Plan.

Execution scope lives inside the DAG. As nodes execute, they accumulate result, usage, error, and errorCode. These values are used for passing NODE_RESULT arguments, classifying errors, making recovery decisions, and final verification. Execution context stays attached to specific nodes, so downstream logic can see the source of every result or failure.

Run scope covers the whole run. Budget tracks resources from planning through verification, Tracer writes events at every stage, and the final RunResult collects status, report, plan, verdict, budget snapshot, and trace events. From it, you can see which plan was built, which nodes executed, where a failure appeared, and what decision the recovery logic made.

Long-term memory, session history, and retrieval over previous runs are outside the scope of this article. The focus here is the context of a single run: request, planning attempt, execution state, and final result.

Executor Verification

After the execution phase, the harness runs ReportVerifier. It checks the structural correctness of the result: the plan contains exactly one final synthesis node, that node completed successfully, all of its dependencies are done, the result implements FinalReport, and the report text is present.

The check is based on tool roles from ToolCatalog. Regular data tools collect inputs, while summarizer_node is marked as FINAL_SYNTHESIS. The verifier finds the final node by tool role, so the result does not depend on the specific node id chosen by the planner.

This verification gate catches basic orchestration errors: empty reports, multiple final nodes, missing dependencies, failed data tools, skipped nodes, and wrong result types. On failure, the orchestrator returns FAILED_VERIFICATION, stores the reason in RunResult, and writes a verification.finish event to the trace.

This version uses structural verification. An LLM judge can be added as a separate layer on top of ReportVerifier when there are criteria for text quality, recommendation relevance, and completeness of the explanation.

Budget and Recovery

The harness tracks budget across several dimensions: tokens, tool calls, wall-clock time, and estimated cost. All of these limits converge into one pressure value. It reports the maximum utilization across all resources, so the run stops on the most constrained limit. This uses max, not an average or weighted score: exceeding any hard limit must stop the run regardless of the state of the other resources.

public synchronized double pressure() {
    return max(
            tokenPressure(),
            toolCallPressure(),
            wallClockPressure(),
            estimatedCostPressure()
    );
}

The budget is updated during planning and execution. When each node starts, the scheduler charges one tool call. After LLM calls, usage metadata turns into token and cost accounting. A budget snapshot goes into trace events and the final RunResult, so after the run you can see how many resources went into planning, execution, and final synthesis.

The second part of operational logic is error classification. The tool layer returns HarnessErrorCode, then ErrorClassifier maps it into one of four groups: VALIDATION, MISSING_INFO, TRANSIENT, or FATAL.

return switch (code) {
    case UNKNOWN_TOOL, MISSING_REQUIRED_ARGUMENT, INVALID_ARGUMENT -> ErrorClass.VALIDATION;
    case MISSING_INFO -> ErrorClass.MISSING_INFO;
    case RATE_LIMITED, TIMEOUT -> ErrorClass.TRANSIENT;
    case TOOL_EXECUTION_FAILED -> ErrorClass.FATAL;
};

After classification, RecoveryPolicy chooses an action. VALIDATION and MISSING_INFO lead to REPLAN, because the problem can be fixed with a new plan. TRANSIENT leads to RETRY for tool execution. FATAL leads to HALT.

return switch (errorClass) {
    case VALIDATION, MISSING_INFO -> RecoveryAction.REPLAN;
    case TRANSIENT -> RecoveryAction.RETRY;
    case FATAL -> RecoveryAction.HALT;
};

Retry logic is intentionally omitted for simplicity. In this model, RETRY refers to transient tool execution failures: RATE_LIMITED and TIMEOUT. In a production version, this should be node-level retry inside DagScheduler: retrying a specific PlanNode, enforcing an attempt limit, using backoff, charging budget for every attempt, and recording separate node.retry events in the trace.

Recovery is expressed through run phases and state transitions. PlanningLoop handles validation failures, ExecutionEngine handles execution failures, and both can move the run into REPLANNING when RecoveryPolicy chooses REPLAN, budget still has room, and maxReplans has not been reached. The next planning attempt receives the original goal, the same tool catalog, and the previous failure context.

Tracing

Every run leaves behind trace events. This is an append-only event log that can reconstruct the execution path: when the run started, how planning and validation went, which nodes started, which completed, where an error appeared, which decision recovery logic made, and what budget state the run had at the end.

A trace event stores technical and operational information in one flat record.

public record TraceEvent(
        Instant timestamp,
        String runId,
        String sessionId,
        String kind,
        String role,
        String nodeId,
        String status,
        Long latencyMs,
        String message,
        BudgetSnapshot budget,
        Map<String, Object> data
) {
}

kind describes the event type: run.start, planning.finish, validation.finish, node.start, node.finish, node.fail, node.skip, execution.finish, recovery.decide, verification.finish, run.finish. role links node events to the tool role: DATA or FINAL_SYNTHESIS. nodeId points to a concrete plan node. latencyMs shows tool call duration. budget records a resource snapshot at the time of the event.

The current implementation uses InMemoryTracer: it stores events in a list and returns a copy at the end of the run. For a local harness, that is enough: RunResult already contains the full trace, which can be printed in the CLI, asserted in tests, or serialized outward.

Trace is especially useful on failures. If execution fails, the events show the failed node, error code, recovery decision, and budget pressure at the time of the error. This turns a run from a black box into a sequence of verifiable facts.

Orchestrator

The orchestrator is implemented as a state machine. A run moves through named phases, and each phase is handled by a small transition step that receives the current RunState and returns the next one.

RunState keeps the current phase, plan, failure context, attempt counter, runtime context, and final result. Recovery uses the same mechanism: a validation or execution failure can return a REPLANNING state with updated failureContext and incremented attempt counter.

RunResult run(RunRequest request) {
    RunState state = lifecycle.create(request);
    while (!state.terminal()) {
        state = transition(state);
    }
    return state.result();
}

private RunState transition(RunState state) {
    return switch (state.phase()) {
        case CREATED -> lifecycle.start(state);
        case PLANNING -> planningLoop.plan(state);
        case VALIDATING -> planningLoop.validate(state);
        case EXECUTING -> executionEngine.execute(state);
        case VERIFYING -> verify(state);
        case REPLANNING -> planningLoop.replan(state);
        case RETRYING -> executionEngine.retry(state);
        case SUCCEEDED, FAILED, BUDGET_EXHAUSTED -> throw new IllegalStateException(...);
    };
}

The code reads like a transition table: one phase, one handler, one returned state. Replanning and retrying are visible as regular transitions.

What Remains Offstage

The next layer is quality evaluation across many runs. A single successful CLI run only shows one specific happy path. Confidence requires eval cases: different user preferences, budget constraints, tool errors, invalid plans, and replan scenarios.

Long-term memory is also a next step. Today, context lives inside one run: goal, failureContext, node results, budget snapshot, and trace events. Sessions will need a separate history store, a policy for selecting relevant past runs, and context limits before sending anything to the planner.

Another open layer is production hardening for tools. Local data tools are safe for a demo, but real tool calls may access the network, read databases, mutate state, or call external APIs. Those tools need timeouts, idempotency, sandboxing, rate limits, audit logs, and human approval for irreversible actions.

Verification can also grow. The current ReportVerifier checks result structure. The next level is domain quality checks: whether recommendations match preferences, whether prices are not invented, whether the explanation is complete, and whether the response format is stable. These checks can be deterministic, LLM-based, or mixed.

The main idea stays the same: every new layer should plug into the harness as a separate part. Eval suite, session memory, production tool policies, and a stronger verification gate should not bloat the orchestrator. The runtime state machine keeps execution order, while new capabilities are added around it through explicit contracts.

The full demo is available at https://github.com/lbobylev/harness-demo.

DEV Community: l3o6

Some Decision-Making Methods for System One Models Like Jev

WSM - Weighted Sum Method

TOPSIS - Technique for Order Preference by Similarity to Ideal Solution

Choosing a Method

Routing OpenCode Tasks with Jev

Fuzz Testing for Java Code Generation

ArchUnit as a Guardrail for AI-Generated Code

Agent-Based Code Generation and Architectural Drift

What Is ArchUnit

What Checks Can Be Performed

Example in a Project

Conclusion

Using Temporal SDK in Haskell

What Is Temporal

Installing and Running Temporal Locally

Temporal SDK and langchain-hs

Core Temporal Components and Their Representation in the Haskell SDK

Workflow

Activity

Starting a Workflow and Sending a Signal

AI and the Erosion of Practice

Minimalistic OpenCode multi-agent configuration

Roles

Agent Configuration Examples

agents/route.md

agents/lite.md

Setting Up Haskell Development in Neovim

Install Haskell tools

Configuring Haskell IDE Support

Configure haskell-tools.nvim

Optional Telescope Haskell Tools extension

Add Treesitter support for Haskell

Add Haskell key mappings

Debugging

Formatting

Install and verify

Hover actions

File REPL

Running Pi Coding Agent for Java Development in Docker Sandbox

Install Docker Sandboxes

Add MCP secrets

Create the Dockerfile

Configure MCP servers

Build and publish the sandbox template

Create the sandbox

Sandbox persistence

Network access control

Start Pi again later

Result

Run Big MoE Models on a 16GB Mac with Flash-MoE

Test Environment

Models

Benchmark Results

Detailed Flash-MoE Comparison

Key Findings

Conclusion

Building an Agentic Harness with Spring AI and LangGraph4j

Building an Agentic Harness with Spring AI

Demo Scenario

Model Call

Tools

Planner Graph

Parallel Graph Execution

Execution Context

Executor Verification

Budget and Recovery

Tracing

Orchestrator

What Remains Offstage

`agents/route.md`

`agents/lite.md`

Configure `haskell-tools.nvim`