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.
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.
| Surface | Weak output | Better artifact |
|---|---|---|
| Hiring agent | Ranked job prose | search_jobs result with apply paths and consent scope |
| Tool calling | Chatty action summary | Typed function call and returned object |
| Diagramming | Mermaid blob or PNG | Self-contained HTML with inline SVG |
| Slides | Flat image deck | Native PPTX objects, charts, notes, transitions |
| Coding agent | Transcript | Worktree, diff, command trace, cost status |
| Benchmark | Score table | Replayable tool trace with limits and spend |
| Small model | Claim about size | Local 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 concept | Why it matters |
|---|---|
| Function signature becomes schema | The allowed call is explicit. |
Literal and Field constraints | The model cannot emit arbitrary values for constrained fields. |
| Tool retrieval above five tools | The active grammar shrinks to reachable tools. |
| Confidence threshold | Low-confidence calls can escalate instead of acting. |
Single .cact tuned model | A 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 output | User cost |
|---|---|
| PNG per slide | The user redraws every fix. |
| SVG preview only | The user can inspect but not edit in normal deck workflow. |
| Native PPTX shapes | The user can edit text, fills, shapes, and layout. |
| Native chart/table objects | The user can edit data and retain office workflow. |
| Speaker notes and narration | The 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:
| Receipt | Reason |
|---|---|
| GPU and driver | A sample means less without the machine. |
| exact model and checkpoint | Users need reproducibility, not "latest." |
| VRAM and batch settings | Failed runs often die here. |
| kernel build path | Optional CUDA should stay optional. |
| clip length and resolution | Quality claims hide in duration. |
| seed and prompt | Evaluation 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.
I favored checks that leave an inspectable object: schema, manifest, returned tool result, package import, file count, module surface, or a clear boundary warning.
| Item | Check | Result | My read |
|---|---|---|---|
| OJCP | .well-known/ojcp.json, MCP initialize, tools/list, search_jobs | Manifest worked. JSON-RPC worked. search_jobs returned three typed mock jobs. | Real protocol surface, even if the data is demo data. |
| Needle | uvx install, import, actual tool-call script | CLI help was poor. Package import worked. Tool call returned Lagos weather result in 14.3s. | Strong small-model artifact. CLI polish needs work. |
| Diagram Design | Clone, count references and assets, read skill | 37 references and 100 HTML assets. Strong SVG and taste gate contract. | Useful skill design: one type at a time, bounded output. |
| PPT Master | Repo and requirements inspection | Native PPTX pipeline is explicit. No npm package. Heavy repo. | Valuable artifact goal. Needs a dedicated deck trial. |
| Orca | Repo metadata, docs inspection, npm package check | Desktop app repo is real. npm orca points to another package. | Strong parallel-agent workbench. Install path requires care. |
| Embabel | README, module tree, Maven POMs | API, MCP, RAG, observability, A2A, providers, test modules. | Enterprise agent shape. Compile test skipped. |
| LTX-2 | Release and pyproject.toml | CUDA-aware package shape, optional kernels, no release assets. | Worth tracking. GPU trial required. |
| Bough | README and release inspection | One JS program per round; no-sandbox warning stated. | The harness idea is sharp because the danger is explicit. |
| Trunchbull | Public site inspection | Tool deploy, isolated workers, budgets, traces, pricing claims. | Good benchmark shape. I did not run a private benchmark. |
| Archer OS | Draft spec inspection | Clear "unseen agent plus unseen app" compatibility test. | Valuable spec, not an implementation. |
| cc-probeline | README inspection | Prices 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
| Project | Why it passed | Caveat |
|---|---|---|
| OJCP | It turns job search and application into typed tools, manifests, consent scope, and apply paths. | v0.1, mock reference data, adoption uncertain. |
| Needle | A local package ran a real tool call with a tiny model engine path. | CLI help is weak, first run downloads from HF. |
| Diagram Design | It treats diagrams as accessible, self-contained HTML/SVG files with type-specific rules. | Description and README disagree on type count. |
| PPT Master | It targets native editable PowerPoint, not flat slide images. | Big surface, model quality and local setup matter. |
| Orca | It frames parallel coding agents as worktrees, diffs, remote sessions, and review loops. | Desktop install and authority surface deserve careful setup. |
| Embabel | It brings typed domain models, planning, MCP, and observability into JVM agent work. | Heavy framework. Needs a real Spring app trial. |
| Bough | It gives the model one program per round and states the lack of sandbox clearly. | Shared checkout and full user authority are dangerous defaults. |
| Trunchbull | It points benchmarks toward tool traces, budgets, and sandboxed runs. | I only inspected the public site. |
| LTX-2 | It exposes the CUDA and kernel boundary instead of hiding media-model setup pain. | No inference run on this machine. |
| cc-probeline | It 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:
| Work | Native artifact |
|---|---|
| Search and application | Manifest plus typed job object. |
| Device or tool control | Function call with constrained arguments. |
| Diagramming | HTML file with inline accessible SVG. |
| Presentations | Editable PPTX with native objects. |
| Coding | Worktree, patch, command output, test result. |
| Benchmarking | Trace, sandbox lease, cost ledger, score. |
| Media generation | Prompt, seed, checkpoint, hardware receipt, output file. |
| Enterprise workflow | Typed 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
- OJCP: Open Job Context Protocol
- GitHub: ojcp-org/ojcp
- GitHub: cactus-compute/needle
- Hugging Face: Cactus-Compute/needle2
- GitHub: cathrynlavery/diagram-design
- GitHub: hugohe3/ppt-master
- GitHub: stablyai/orca
- GitHub: andreylukin/bough
- GitHub: embabel/embabel-agent
- GitHub: Lightricks/LTX-2
- Trunchbull
- GitHub: coachpato/archer-os
- GitHub: labzink/cc-probeline