---
title: 'In the News: August 24, 2026'
description: 'A Purdue study on compiling natural-language agent workflows finds faithfulness checking, not compilation alone, drives most of the reliability gain.'
canonical_url: 'https://darkfactory.dev/news/2026-08-24-morning'
markdown_url: 'https://darkfactory.dev/news/2026-08-24-morning.md'
collection: news
date_published: '2026-08-24T06:35:00-04:00'
date_modified: '2026-08-24T06:35:00-04:00'
---

# In the News: August 24, 2026


Faithfulness checking accounts for most of the reliability gain when a natural-language workflow is compiled into an executable form. A second paper proposes keeping authorization outside the agent entirely once that workflow runs unattended.

## 1. Checking a compiled workflow for faithfulness does most of the reliability work

**[Natural-Language Workflows Are Not Software Yet: Artifact-Driven Compilation for Reliable Agent Execution](https://arxiv.org/abs/2608.21341)** · Xiangzhe Xu, Hanxi Guo, Guangyu Shen, Siyuan Cheng, Xiangyu Zhang, Purdue University · arXiv, August 21, 2026

The authors' starting claim is that a natural-language workflow handed to an agent is not yet software: it carries no explicit data-dependency or control-transfer declarations, so an agent can drift from what was actually specified without anyone noticing until the output is wrong. Their proposed fix compiles the workflow into an artifact-driven form, refines it with constrained optimization, and checks it for faithfulness by decomposing it into local obligations and running scenario-based dry runs before execution. Tested across 488 instances spanning 11 domains, an ablation that isolated the faithfulness-validation step on its own found it responsible for a 16 percentage point improvement.

**Why it matters:** For anyone specifying agent workflows in plain language and hoping the agent does what was meant, this is a concrete alternative to hoping: compile the spec, then check the compiled form for faithfulness before running it. The ablation result matters because it says where the gain actually comes from. Most of it is the validation step, not the act of compiling on its own.

## 2. One harness, three surfaces, authorization held outside the agent entirely

**[Applying Anthropic Primitives at Large Enterprises: Harness Paradigm for Knowledge Work](https://arxiv.org/abs/2608.20622)** · George Salapa, G.S. s.r.o. / PwC Austria · arXiv, August 20, 2026

Salapa lays out a deployment pattern for running one unmodified harness across a terminal, an unattended cron job, and a business-facing chat surface under a single identity, with authorization logic held entirely outside the harness process rather than baked into it. In place of per-operation tool schemas, including MCP, the paper argues for credential-scoped tooling and a call envelope that requires the agent to self-declare risk on each call it makes. Calls flagged as risky are then judged by a fresh model instance rather than graded by the same context that made the call. The paper states plainly that no benchmark accompanies it and that its evaluation is specific to Azure.

**Why it matters:** This is a pattern for the point an organization has more than one surface running the same agent and does not want a separate permission system for each. The self-declared risk flag paired with a fresh-instance review is a specific, checkable alternative to letting an agent grade its own risky calls, though it is worth noting this is a single-author proposal without an accompanying benchmark.