~/blogai-work-needs-native-artifacts-august-2026.md
cchu@nycu:~/blog$ cat ai-work-needs-native-artifacts-august-2026.md
2026.08.1316 min[ai-agents][ml-systems][developer-tools][agent-infrastructure]

AI Work Needs Native Artifacts

A field note on OJCP, Needle, Diagram Design, Orca, PPT Master, Embabel, LTX-2, Bough, Trunchbull, and why useful agent systems now need outputs that other tools can inspect.

August 12 had a different shape than the usual model day. The useful work sat in objects I could touch: a .well-known manifest, an MCP tool schema, a native deck, a diagram HTML file, a local tool-call result, a worktree, a model engine, a trace.

That is the line I came away with: AI work needs native artifacts.

An answer in a transcript is too soft. It can sound right and still leave nothing behind for the next system to verify. A stronger tool gives you an object with a contract:

  • a job object an agent can search and apply to
  • a tool-call result with typed arguments
  • an editable deck, not screenshots of slides
  • a diagram file with accessible SVG metadata
  • a tiny model engine that runs a tool call
  • a worktree and diff that survive the session
  • a trace with cost, tool use, and stop reason

The model can still be impressive. I care more about the object it leaves.

Native artifact map

A useful agent system turns intent into a native artifact, then leaves proof close enough for another tool or person to inspect.

The Work Object Is the Product

The old demo path was "ask the model and watch the answer." The newer path is "ask the system and inspect the artifact." That sounds like a small wording change. In practice, it changes the whole proccess.

SurfaceWeak outputBetter artifact
Hiring agentRanked job prosesearch_jobs result with apply paths and consent scope
Tool callingChatty action summaryTyped function call and returned object
DiagrammingMermaid blob or PNGSelf-contained HTML with inline SVG
SlidesFlat image deckNative PPTX objects, charts, notes, transitions
Coding agentTranscriptWorktree, diff, command trace, cost status
BenchmarkScore tableReplayable tool trace with limits and spend
Small modelClaim about sizeLocal package, cached engine, returned tool result

I used that filter before giving anything space in this post. Star velocity alone did not pass. Big claims did not pass. A repo passed when I could see how a user, agent, or CI system would inspect the output after the clever part ended.

OJCP Passed the Protocol Test

OJCP is the most concrete item I checked because it exposes an agent-facing contract instead of a landing-page idea. The public site describes a protocol for agent-consumable job data. The part that matters is the discovery and MCP surface.

I fetched:

GET https://ojcp.dev/.well-known/ojcp.json

The manifest returned ojcp_version: 0.1, provider metadata, an MCP endpoint, six tools, a jobs feed endpoint, apply path types, auth notes, and rate limits. A plain browser GET to /api/mcp returned 406, which is fine. MCP expects protocol framing rather than a static JSON URL.

Then I sent a proper JSON-RPC request:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"codex-smoke","version":"0.0.1"}}}

The server returned protocol version 2025-06-18, tool capabilities, and server info. tools/list returned typed schemas for search_jobs, get_job_detail, get_employer_context, begin_application, submit_application, check_application_status, and find_ojcp_providers.

The useful test was a real tool call:

{
  "name": "search_jobs",
  "arguments": {
    "query": "remote machine learning engineer",
    "location": { "remote_ok": true },
    "pagination": { "limit": 3 }
  }
}

It returned three mock jobs from a total of six. The first result had an OJCP id, employer, salary range, remote policy, skills, team context, urgency, and two apply paths. One path allowed agent submission through a provider-hosted URL. The ATS-direct path did not.

That split is the product. A hiring agent should know which path it can use without screen-scraping an apply form and pretending it understood consent. The agent_declaration schema also asks for agent_id, acting_on_behalf_of, interaction mode, and user consent token. That is the right annoying detail.

OJCP is still a v0.1 spec with mock data. I would not call it infrastructure yet. I do call it valuable because it makes the job object visible. A job is no longer a paragraph. It becomes an action surface with apply paths, privacy scope, and status check.

Needle Made the Tiny Model Claim Less Cute

Needle 2 claims a 45M parameter tool-calling model in a 14 MB engine for tiny devices. Many small-model projects sound better than they run. This one passed a real smoke test on my Windows machine.

First, the rough part:

uvx --from cactus-needle needle --help

It installed the package and printed only:

Check the readme

The CLI help path was weak. A tool with a command named needle should list commands, flags, or at least playground, finetune, and build.

The package itself was real:

uvx --from cactus-needle python -c "import needle; print(needle.__version__)"

That printed 2.0.1 and exposed Needle, tool, extract, Field, and schema helpers. Then I ran a toy tool call:

from needle import Needle, tool

@tool
def get_weather(city: str):
    "Get weather for a city."
    return {"city": city, "temp_c": 27}

agent = Needle(tools=[get_weather])
print(agent.run("weather in Lagos")["results"])

It returned:

[{'city': 'Lagos', 'temp_c': 27}]

The first run took 14.3 seconds and warned that Hugging Face cache symlinks are degraded on this Windows setup. It also warned about unauthenticated HF Hub requests. Those are normal first-run frictions, and they are better than fake smoothness.

The product value is a constrained local action layer:

Needle conceptWhy it matters
Function signature becomes schemaThe allowed call is explicit.
Literal and Field constraintsThe model cannot emit arbitrary values for constrained fields.
Tool retrieval above five toolsThe active grammar shrinks to reachable tools.
Confidence thresholdLow-confidence calls can escalate instead of acting.
Single .cact tuned modelA device can carry one artifact, not a model folder mess.

Small models win when they own a narrow job. Tool choice, extraction, device control, and local triage fit that shape. I would still route ambiguous language to a larger model, but I do not want a cloud model deciding whether the lamp dimmer should accept 30, "30%", or "cozy mode" when a local constrained decoder can keep the call inside a schema.

Diagrams Need Their Own Contract

Diagram Design looks like a simple skill pack at first. It is more interesting than that. I cloned it and counted 37 reference files plus 100 HTML assets under the diagram skill. The skill covers 27 diagram types in the README, with type-specific references, import paths for draw.io and Mermaid, output dials, complexity budgets, and an accessible SVG contract.

The important bit is the taste gate. The skill tells the agent to load one type reference, keep the diagram under a node and connector budget, use accessible <title> and <desc>, avoid diagonal connectors, and write a self-contained HTML file with inline SVG.

That is a native artifact contract. A diagram should not be a model's vibe about architecture. It should be a file with:

diagram type
canvas size
audience level
node budget
connector rules
label masks
accessibility metadata
export path
fidelity ledger for imports

I like that it imports Mermaid by extracting structure and redrawing instead of copying Mermaid's layout. A renderer is a poor design system. A good agent can use Mermaid as source material and still make a cleaner diagram for a deck or report.

The repo has a small contradiction: the GitHub description says 29 types, the README says 27, and the skill file says 27. That version drift is small, but a skill pack should fix it because agents read descriptions as doctrine.

Decks Are Not Images

PPT Master sits in the same family as Diagram Design, but with higher blast radius. It wants the agent to create editable native PowerPoint decks. The README is long because the domain is long: templates, slide masters, native shapes, charts, tables, transitions, animations, notes, narration, image acquisition, quick mode, and export.

I did not install the whole thing. The repo has more than 14,000 files in the recursive tree I inspected, and the requirements chain lives under skills/ppt-master/requirements.txt. A full run belongs in a deliberate deck job, not a daily news automation.

The repo still passed my value filter because it is obsessed with the right artifact. It does not settle for "AI made slides." It says the deck should stay editable in PowerPoint, with native DrawingML objects and optional native chart/table replacements.

For work, that distinction matters more than prettiness:

Slide outputUser cost
PNG per slideThe user redraws every fix.
SVG preview onlyThe user can inspect but not edit in normal deck workflow.
Native PPTX shapesThe user can edit text, fills, shapes, and layout.
Native chart/table objectsThe user can edit data and retain office workflow.
Speaker notes and narrationThe artifact can move into rehearsal or video.

A deck is a living office object. Agents that flatten it into images save time at generation and charge it back during revision. PPT Master has a big surface, but it points at the right target.

Parallel Agent IDEs Need Install Honesty

Orca has a strong pitch: run multiple coding agents in parallel worktrees, review diffs, use desktop and mobile surfaces, drag files into agents, operate a browser, and keep GitHub or Linear in the same enviroment. The repo is also serious in size: my tree query saw 13,652 paths. It has Windows, Linux, macOS, mobile, Electron, native modules, tests, and docs assets.

I did not install the desktop app. I checked the public package path first:

npm view orca version description bin --json

That returned Plotly's old image-export package, not Stably's Orca. Good to know. The app uses Homebrew casks, desktop downloads, and a repo build path, not npx orca.

That install honesty matters. Agent IDEs carry authority: terminal sessions, worktrees, screenshots, browser control, account state, and sometimes remote SSH. A wrong install path should fail early.

Orca's value is the workbench around several agents:

worktree per attempt
agent session per lane
diff review surface
comment back to agent
usage and rate-limit status
remote/SSH worktree path
mobile monitor

The caveat is surface area. A parallel-agent IDE can become an authority blender if the user cannot see which agent touched which worktree, which account paid for which model, and which diff won. Orca looks like it understands that problem, but a daily automation should not install a desktop control plane to prove it.

Bough is a smaller, rougher counterpoint. It describes a coding agent that writes one JavaScript program per round. That is a clean harness idea because loops and branches live inside the program instead of five tool-call turns. The README also says the part many repos hide: no isolation boundary. Programs run as the user with filesystem, network, subprocesses, and npm: imports.

That warning earned trust. An agent harness without a sandbox can still be useful. It should say the danger in plain text.

JVM Agents Are Coming From the Enterprise Side

Embabel is a broad multi-module Kotlin and Java framework with API, MCP, OpenAI, Anthropic, RAG, observability, A2A, shell, starters, test support, and ONNX modules. The README frames flows around actions, goals, conditions, domain objects, and dynamic planning. It also leans on Spring and JVM typing.

I did not compile it. The root POM is a snapshot-heavy Maven reactor, and a proper trial would need Java, Maven cache, provider keys for any LLM path, and time. I inspected the module shape and the POMs for MCP and observability instead. The MCP module pulls Spring AI MCP server pieces. The observability module pulls Micrometer tracing, AspectJ, and OpenTelemetry API.

That is the useful part: enterprise agent frameworks will look boring. They will care about typed domain objects, planning, transactions, tracing, and testability. Python agent frameworks move faster, but many companies already have the real work in Spring services and JVM data models.

The artifact here is a typed flow:

domain object
action
goal
condition
plan
trace span
test
MCP endpoint

That shape fits bank, insurance, logistics, healthcare, and internal tools. The risk is abstraction weight. A framework can bury the simple action under too many concepts. Embabel deserves a real project test before I trust the ergonomics, but the direction is right.

Media Models Need Hardware Receipts

LTX-2 is an official Python inference and LoRA trainer package for an audio-video generative model. The latest GitHub release I checked was v1.2.0, published on August 11. The release had no attached assets. The repo's pyproject.toml tells a more useful story than the release page: workspace packages, optional compiled CUDA kernels, a CUDA 13.2 toolchain path, cuDNN pinning, and an explicit note that a plain uv sync should not force a CUDA build.

I did not run inference. This Windows machine is the wrong trial bench for a media model that likely wants a planned GPU enviroment. The useful thing to check was whether the package tells the user where the hardware edge lives. It does.

The media-model lesson is simple: generative video and audio projects should publish hardware receipts alongside samples. I want to see:

ReceiptReason
GPU and driverA sample means less without the machine.
exact model and checkpointUsers need reproducibility, not "latest."
VRAM and batch settingsFailed runs often die here.
kernel build pathOptional CUDA should stay optional.
clip length and resolutionQuality claims hide in duration.
seed and promptEvaluation needs repeatable input.

LTX-2 seems to know this area is rough. The package metadata separates core sync from kernel builds, which is a good sign.

Tool-Native Benchmarks Are the Better Leaderboard

Trunchbull describes itself as a tool-native benchmarking platform. I could not run a public benchmark without signing up, so I kept it below the projects with actual local tests. The public site still had a useful product shape: deploy tools from GitHub, run them against OpenRouter models, enforce hard ceilings for steps, tokens, and spend, then inspect traces.

The pricing table is also specific: free tier with 1,000 tool calls per month, and an open beta plan with 250,000 tool calls plus sandbox hours. Specific numbers help. They make the budget shape visible.

Benchmarks for agents need tools, sandboxes, and money limits. A model score with no action trace is too thin. If one model wins because it called the right tool with the right argument and another failed because it burned steps on search, the trace matters more than the final score.

My Trial Bench

I kept the bench small and mostly non-invasive: Windows, PowerShell, public endpoints, package metadata, temp clones, no paid model calls, no desktop app install, no GPU media run.

Trial bench for native artifacts

I favored checks that leave an inspectable object: schema, manifest, returned tool result, package import, file count, module surface, or a clear boundary warning.

ItemCheckResultMy read
OJCP.well-known/ojcp.json, MCP initialize, tools/list, search_jobsManifest worked. JSON-RPC worked. search_jobs returned three typed mock jobs.Real protocol surface, even if the data is demo data.
Needleuvx install, import, actual tool-call scriptCLI help was poor. Package import worked. Tool call returned Lagos weather result in 14.3s.Strong small-model artifact. CLI polish needs work.
Diagram DesignClone, count references and assets, read skill37 references and 100 HTML assets. Strong SVG and taste gate contract.Useful skill design: one type at a time, bounded output.
PPT MasterRepo and requirements inspectionNative PPTX pipeline is explicit. No npm package. Heavy repo.Valuable artifact goal. Needs a dedicated deck trial.
OrcaRepo metadata, docs inspection, npm package checkDesktop app repo is real. npm orca points to another package.Strong parallel-agent workbench. Install path requires care.
EmbabelREADME, module tree, Maven POMsAPI, MCP, RAG, observability, A2A, providers, test modules.Enterprise agent shape. Compile test skipped.
LTX-2Release and pyproject.tomlCUDA-aware package shape, optional kernels, no release assets.Worth tracking. GPU trial required.
BoughREADME and release inspectionOne JS program per round; no-sandbox warning stated.The harness idea is sharp because the danger is explicit.
TrunchbullPublic site inspectionTool deploy, isolated workers, budgets, traces, pricing claims.Good benchmark shape. I did not run a private benchmark.
Archer OSDraft spec inspectionClear "unseen agent plus unseen app" compatibility test.Valuable spec, not an implementation.
cc-probelineREADME inspectionPrices Claude Code turns from local logs; offline render path.Narrow tool, concrete receipt. I did not install it.

I cut several loud candidates. Generic agent persona packs did not add much after last week's checks. Large RAG systems did not need another paragraph unless they exposed a new artifact. Financial-market foundation models are interesting, but I did not have the right dataset and backtest enviroment for a responsible read.

The Repos That Passed

ProjectWhy it passedCaveat
OJCPIt turns job search and application into typed tools, manifests, consent scope, and apply paths.v0.1, mock reference data, adoption uncertain.
NeedleA local package ran a real tool call with a tiny model engine path.CLI help is weak, first run downloads from HF.
Diagram DesignIt treats diagrams as accessible, self-contained HTML/SVG files with type-specific rules.Description and README disagree on type count.
PPT MasterIt targets native editable PowerPoint, not flat slide images.Big surface, model quality and local setup matter.
OrcaIt frames parallel coding agents as worktrees, diffs, remote sessions, and review loops.Desktop install and authority surface deserve careful setup.
EmbabelIt brings typed domain models, planning, MCP, and observability into JVM agent work.Heavy framework. Needs a real Spring app trial.
BoughIt gives the model one program per round and states the lack of sandbox clearly.Shared checkout and full user authority are dangerous defaults.
TrunchbullIt points benchmarks toward tool traces, budgets, and sandboxed runs.I only inspected the public site.
LTX-2It exposes the CUDA and kernel boundary instead of hiding media-model setup pain.No inference run on this machine.
cc-probelineIt converts local Claude Code logs into per-turn cost and cache receipts.Claude Code-specific and not installed in this run.

A Native Artifact Contract

I would design new agent products around a short artifact contract. The transcript can stay, but it should not carry the system.

artifact id
artifact type
source inputs
schema or file format
model route
tool calls
cost and step limits
local or remote boundary
validation result
human approval state
replay or export path

Each class of AI work then gets its own native object:

WorkNative artifact
Search and applicationManifest plus typed job object.
Device or tool controlFunction call with constrained arguments.
DiagrammingHTML file with inline accessible SVG.
PresentationsEditable PPTX with native objects.
CodingWorktree, patch, command output, test result.
BenchmarkingTrace, sandbox lease, cost ledger, score.
Media generationPrompt, seed, checkpoint, hardware receipt, output file.
Enterprise workflowTyped domain object, plan, trace span, transaction result.

The user should not need to trust the assistant's memory. The artifact should hold enough state for another system to continue the work.

Close

AI tooling is moving from answers into work surfaces. That is good. It also raises the bar. If an agent applies to jobs, it needs a manifest and consent record. If it controls a device, it needs constrained tool calls. If it draws a diagram, it needs an editable file with a design contract. If it writes code, it needs a worktree and receipts. If it benchmarks models, it needs trace and cost data.

The durable product is the artifact, not the chat around it.

The systems I trust more now have one habit: they leave behind something boring enough to inspect.

Sources