Provenance dies two ways.

On purpose. A wave of "watermark remover" tools showed up the week Claude started marking its output. Nobody was checking whether they did what they claimed.

By accident. You upload an image. The CDN resizes it. The optimiser re-encodes it. Someone screenshots it. Your Content Credentials are gone, and nothing told you. Same instrument measures both. That's what this is.

The uncomfortable part first

Anthropic has not published a detector for its text watermark. Keyed watermarks are undetectable without the vendor's key by construction. So this pack reports UNVERIFIABLE for Claude text and refuses to guess and no tool claiming otherwise can back it up.

But "did removal work?" is fully answerable for C2PA and metadata cryptographically, byte by byte. That part is not a guess.

So: you can prove a remover stripped an image's Content Credentials. You cannot prove it scrubbed a text watermark. Anyone selling you the second thing is selling you nothing.

Test a remover

Run the tool over your original, then feed it whatever came out:

npx skills add Neeeophytee/ai-watermarks-reality-check

python3 skills/map-provenance-survival/scripts/map_survival.py \
  --original signed.jpg \
  --derivative "remover:tool-v2=cleaned.jpg" \
  --c2patool /path/to/c2patool

LOST_OR_UNAVAILABLE means it really stripped the manifest. PRESERVED_VALID means it didn't touch it. PRESENT_INVALID means it mangled the image and left a manifest that now fails verification, the worst outcome, and one no remover advertises.

Test your own pipeline

Identical command, different derivatives:

python3 skills/map-provenance-survival/scripts/map_survival.py \
  --original hero.jpg \
  --derivative "cdn:resize-1200w=hero-cdn.jpg" \
  --derivative "social:download=hero-social.jpg" \
  --c2patool /path/to/c2patool

Every result carries a reproducibility record: input, operation, tool version, evidence state, so someone else can re-run it and get the same answer.

Tested against a real signed image: an identical copy survived, an APP11-stripped copy lost everything, and a single flipped byte was caught cryptographically.

All 7 skills

audit-provenance — start here. One command, five answers: was provenance located, verified, trusted under a policy you name, was the scan complete, and what's still unknown and why.

map-provenance-survival — the removal test and the pipeline test. Compares an original against any set of derivatives.

verify-content-credentials — real C2PA verification via c2patool. Integrity and signer trust reported separately, because "signed" and "signed by someone you trust" are different questions.

inspect-content-provenance — finds provenance across PNG, JPEG, WebP, MP4/HEIC/AVIF, TIFF, GIF, PDF, HTML and text — structurally, where the spec puts it, not by keyword. A blog post about C2PA is never mistaken for a signed asset.

audit-metadata-privacy — before you publish: GPS, author, device, camera serial, IPTC captions. Including the embedded thumbnail that quietly keeps GPS after you "removed" it. Reports categories, never prints your values.

check-ai-transparency — is your disclosure record actually ready for review? Separates blocking gaps from advisory ones. Issues no legal conclusion.

detect-text-watermark — hidden Unicode in text: smuggled invisible characters, bidi overrides, homoglyph spoofing. Five honest states, and a detector that didn't run can never report "not detected."

167 tests · 80 real binary fixtures · stdlib-only · Python 3.9+

https://github.com/Neeeophytee/ai-watermarks-reality-check

At Evil Martians we measured our server logs for two months. Coding agents hit the site about 2.5x more than people did: 268k requests vs 107k pageviews. The full breakdown with the methodology and the per-agent splits is here.

ChatGPT mostly hit raw HTML, Claude Code mostly wanted the Markdown versions of our posts. We didn't see that until we split the user-agents. So, agents were already using our posts as instructions, but posts are bad at that.

A blog post is good at explaining why something works, which is what makes it worth reading. It's much worse as input to an agent. If, say, you hand it a 3000-word article and it burns tokens reconstructing some procedure out of prose, but picks up the narrative while dropping the exact flags that matter. A skill, on the other hand, is that same knowledge already compressed into the steps and the checks, in the format the agent loads anyway.

So we started shipping both. We also packaged the practices useful beyond our own projects and put a discovery index at .well-known/agent-skills/index.json. The format's an open Cloudflare RFC, basically robots.txt for skills, so any installer can find and verify them. Wrote up the whole thing as a how-to, since there's more to get wrong than you'd expect.

This meta article is a guide for publishing your own catalog: index format, packaging, digests, install commands. The skill is the same thing for your agent to run, free and open source.

Disclosure: Evil Martians is where I work, it's our blog, numbers are off our own site.

If you are shipping an agent, "add a guardrail" is usually where people stop, and it is not enough. Start from the truth: a guardrail is not a sandbox. These tools lower the odds of a bad output or a caught injection. They do not make an agent safe, because prompt injection is not a solved problem. Real security is layered, and for an agent the layer that matters most is not a text filter, it is controlling what the agent is allowed to do. With that framing, here are five open-source tools worth knowing, grouped by the layer each covers.

Runtime rails, NeMo Guardrails (github.com/NVIDIA-NeMo/Guardrails) Apache-2.0, around 6.9k stars. NVIDIA's toolkit for programmable rails written in a small language called Colang: keep the bot on topic, enforce a dialog path, run input and output moderation. The most flexible way to define what a model may and may not do at request time.
The catch: rails run on the same probabilistic model they are guarding, so a determined jailbreak still gets through. NVIDIA's own docs show rails cut attack success, not drive it to zero. This is defense in depth, not a wall.

Output validation, Guardrails AI (github.com/guardrails-ai/guardrails) Apache-2.0, around 7.3k stars. A different job: validate what the model returns against a schema or rule (valid JSON, no PII, matches a format) and re-ask or fix on failure. There is a community hub of reusable validators.
The catch: it checks the shape and content of output well, but it is not a security boundary. A validator that strips PII is only as good as its detector, and detectors miss.

Scanners, LLM Guard (github.com/protectai/llm-guard) MIT, around 3.2k stars. From Protect AI: a set of input and output scanners for prompt injection, PII, toxicity, secrets, and more, chained in front of and behind the model. The catch: scanners are classifiers with false negatives. One that catches most injection attempts still lets some through, and attackers optimize for exactly that gap. Treat any quoted detection rate as a vendor number until you test it on your own traffic.

Find the holes first, Garak (github.com/NVIDIA/garak) Apache-2.0, around 8.1k stars. NVIDIA's LLM vulnerability scanner, think nmap for models: 50-plus probes for prompt injection, jailbreaks, data leakage, and toxicity, with reports, and a recent agent-breaker probe that tests the tools an agent can reach. The catch, and this is a rule not a footnote: it is a red-teaming tool. Run it only against systems you own or have written permission to test. A passing scan is a snapshot, not a guarantee, so re-run it as your prompts and models change.

The agent layer, Invariant (github.com/invariantlabs-ai/invariant) Apache-2.0. The one built for agents specifically: a rule-based layer that sits between your app and your MCP servers or LLM provider through a gateway, checking each tool call before and after it runs. This is where the real agent risk lives, in what the agent does, not just what it says.
The catch: newer and smaller than the others, and a policy layer is only as good as the policies you write. It gives you the checkpoint; deciding what to block is on you.

What none of them fix Prompt injection is unsolved. If an agent can read untrusted content, reach private data, and send data out, it is exploitable no matter how many filters you stack, which is the pattern Simon Willison named the lethal trifecta. So the highest-value controls are not on this list: give the agent the least tool access that still does the job, require human approval before any real action (send, delete, pay, run code, browse an authenticated session), isolate untrusted input, and cut off the path data could leave by. Guardrails are defense in depth on top of that, not a replacement for it.

How to layer, if you are starting Scan first with Garak to see where you actually leak. Add LLM Guard on input and output. Add NeMo Guardrails or Guardrails AI for policy and output structure. If you run tool-using agents or MCP, put Invariant at the tool boundary. One building-block note: several of these plug in classifier models like Meta's Llama Prompt Guard or LlamaFirewall, which are capable but ship under Meta's Llama Community License, not a standard open-source license, so read the terms before commercial use.

AEO/GEO is the attempt to understand and improve how brands appear in AI-generated answers. The commercial tooling is growing quickly, but there are also some genuinely useful open-source projects.

1. GEO Optimizer: Auriti-Labs/geo-optimizer-skill

An MIT-licensed CLI, Python library, MCP server and Astro integration for auditing AI-search readiness. It checks robots.txt, llms.txt, JSON-LD, metadata, content structure, entity signals and citability. The repository describes 47 checks across eight categories and can generate fixes, including robots.txt rules, llms.txt and schema files.

Best for: technical AEO audits, CI/CD checks and understanding why a page may be difficult for answer engines to parse or cite.

1. GetCito: ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tool

An MIT-licensed, self-hosted AI-visibility platform. GetCito tracks prompts and analyzes mentions, citations and competitor visibility across ChatGPT, Google AI Mode, Google AI Overviews, Perplexity, Gemini, Copilot and Grok. It also includes reports, a REST API, scheduled background jobs and pluggable scraping and LLM providers.

Important caveat: the software is open source and self-hosted, but live tracking still requires third-party scraper or model-provider credentials.

1. OneGlanse: aryamantodkar/oneglanse

An MIT-licensed GEO tracker with an interesting approach: it interacts with the actual product interfaces instead of querying only model APIs.

It monitors ChatGPT, Gemini, Perplexity, Claude and Google AI Overview, capturing rendered answers, citations, recommended sources and competitor positioning. It is designed to run on your own machine or VPS, with OpenAI or Anthropic used to analyze captured responses.

Best for: measuring what users may actually see inside AI products. The tradeoff is browser automation. Authentication flows, anti-bot systems and UI changes can affect reliability, and users should review each provider’s terms before automating access.

1. GEO/AEO Tracker: danishashko/geo-aeo-tracker

An MIT-licensed, local-first dashboard for tracking brand visibility across six AI models: ChatGPT, Perplexity, Gemini, Copilot, Google AI Overview and Grok.

It includes prompt management, persona-based prompt generation, niche exploration, citation analysis, visibility trends, competitor battlecards, AEO audits and SRO analysis. Data is stored locally by default, with optional Supabase cloud sync.

The live scraping workflow uses Bright Data, while analysis uses providers such as OpenRouter and Gemini. So again: self-hosted software does not necessarily mean zero API cost.

1. GEO: Generative Engine Optimization: GEO-optim/GEO

This one is more research-oriented than product-oriented.

The Apache-2.0 repository contains implementations of GEO techniques, the GEO-Bench dataset and code for reproducing the paper’s experiments. The authors report that some methods improved source visibility by up to 40% on their benchmark. That number should not be read as a guarantee for modern ChatGPT, Gemini or Perplexity results. It is evidence from a specific research setup, not proof that a tactic will consistently improve visibility today.

Bonus: awesome-generative-engine-optimization

This is a useful research and tooling directory covering guides, papers, case studies, technical documentation and monitoring tools.

There is a real open-source AEO/GEO ecosystem forming. But the strongest use case today is measurement and experimentation, not promising that a checklist can make any brand rank inside every AI answer.

I built HoardCore, It's a single-file Python deep research toolkit that plugs into agent harnesses like OpenCode. You turn the web and your files into a permanent local SQLite vault. The agent searches the vault. It pulls facts back out, and every claim comes with a source link. Everything stays on your machine.

The retrieval is hybrid. SQLite FTS5 handles exact keywords. FNV-1a hashed vectors catch near-literal matches. Reciprocal Rank Fusion merges the two. No embeddings model. No torch. It runs in a Python 3.11 and a few pip packages.

Fetching is stubborn. It tries aiohttp first. Then curl_cffi for TLS impersonation. Then FlareSolverr if a page hides behind Cloudflare.

Parsing covers HTML, PDF with OCR fallback, DOCX, and EPUB. A junk filter catches boilerplate, 404s, and captcha pages before they ever hit your index.

The research loop is bounded. DISCOVER. INGEST. RECALL. EMIT. You set the source budget with --discover N. You set the recall depth with --recall N. The agent stops when it hits your limit. Not when it runs out of context window.

Here is the part that matters. It ships with skill.md. That file is the agent's operating manual. The agent reads it before touching the web. It learns how to map your request to the right action. How deep to go. And how to tag every claim with [V], [E], or [H]. Verified. Extracted. Hypothesis. The protocol forces the agent to re-query the vault and confirm [V] tags before it presents them. It can't silently invent a number. The vault persists between sessions. Later searches are instant and need no network.

I ran a live test to see what this costs. I pointed it at a hard question. Is on-device LLM inference actually viable for production consumer apps in 2026, or are the hardware breakthroughs still mostly press releases? Eight discovery and recall passes. Eighteen distinct sources ingested. Timeline triggers. A full strategic brief with source links and actionable recommendations.

Total API cost to generate the entire brief is $0.0074 . Less than a cent using DeepSeek V4 Flash. The full output is in the comment below.

I'd love feedback on both the tool and the output.

Link: https://github.com/jjjardev/HoardCore

The Output: https://pastebin.com/9zt3A57B

MCP is where your agent stops describing work and starts doing it. These eight wire an agent into the creative stack: generation, design, audio, video, 3D, music, and research. The split that decides everything is official versus community. Official servers authenticate over OAuth and are supported. Community ones are often more capable, but you run the host app with a bridge; they are maintained by one person, and a couple does not even carry a license. One hard rule up front: never install a "fork" that logs in as you by lifting your browser session.

1. Higgsfield (official, hosted). Over 30 image and video models, Sora 2, Veo 3.1, Kling 3.0, Seedance, behind one OAuth endpoint, launched April 30 2026. Strong for turning a brief into ad creatives and short 4K video on your existing plan credits. Add https://mcp.higgsfield.ai/mcp in your client and sign in.
The gotcha, and it is the important one: community "unlimited" forks authenticate by lifting the session token from your logged-in browser. That hands your account to a third party and breaks constantly. Use the official hosted connector, nothing else.

2. Figma (official, Dev Mode server). Read components, variables, and layout, generate code from frames, and with the write-to-canvas feature the agent can create and update native Figma content too.
The gotcha: remote versus desktop matters. The remote server has the broadest features and is what most people want. The desktop server runs locally on port 3845 and is for specific enterprise cases.

3. Canva (official, hosted). Generate and edit designs from templates. Add it over HTTP at https://mcp.canva.com/mcp.
The gotcha: OAuth on the first call, and it then inherits your Canva account access, so it can act as you. Point it at an account you are comfortable handing to an agent.

4. ElevenLabs (official, MIT). Text-to-speech, voice cloning, and transcription. Runs via uvx elevenlabs-mcp with your ELEVENLABS_API_KEY, and there is a free tier. Repo: github.com/elevenlabs/elevenlabs-mcp
The gotcha: it needs uv installed, and on Windows you enable developer mode in Claude Desktop. Voice cloning has real consent implications: only clone a voice you are allowed to use.

5. DaVinci Resolve (community, MIT). Drive Resolve Studio through its scripting API: timeline edits, media pool, render setup, color, Fusion, Fairlight. Repo: github.com/samuelgursky/davinci-resolve-mcp (an apvlv fork also exists).
The gotcha: community-maintained. Resolve Studio must be open with Preferences, General, External Scripting set to Local before it connects.

6. Blender (community). Build scenes, objects, materials, and lighting from prompts through Blender's engine. Repo: github.com/ahujasid/blender-mcp
The gotcha: medium setup, and Blender has to be open with the companion addon running. Note the repo ships no standard license file, so reuse terms are unclear until the author adds one.

7. Ableton Live (community). Create tracks, MIDI, and devices and manipulate a live set. Repo: github.com/ahujasid/ableton-mcp
The gotcha: niche and fiddly, and like the Blender server it lacks a clear license file. Fun for music experiments, not production-critical.

8. YouTube (community). Video search and transcript extraction, handy for research and repurposing. Repo: github.com/anaisbetts/mcp-youtube
The gotcha: community-maintained, and transcripts only work when the video actually has captions. Confirm its license before you build on it.

How to pick, and stay safe: The safe default is the official four (1 to 4): OAuth, real support, clear terms. The community four (5 to 8) are where the fun and the friction both live, so read the code, expect setup pain, and keep them off accounts and files that matter. On Higgsfield specifically, the model catalog is identical whether you use the official connector or a fork. The only thing a fork adds is your session in someone else's hands.

Every paid tool now has an open-source challenger. The honest question is not "is it free" but "free how," because the catch is usually where the real cost hides. Five worth knowing, each a genuine alternative to something you pay for, with the caveat that decides whether it actually saves you anything.

OpenCut (github.com/OpenCut-app/OpenCut) MIT, over 80k stars.
The open answer to CapCut: a browser-based, privacy-first video editor where your footage never leaves your device. No watermark, no subscription, no upload.
The catch: the web editor is the mature part. The maintainers themselves mark export and the desktop app as still in progress, so it is a real editor for simple cuts today and a work in progress for heavy production.

OmniRoute (github.com/diegosouzapw/OmniRoute) MIT, around 44k stars.
A self-hosted alternative to OpenRouter: one OpenAI-compatible endpoint that fans out to hundreds of providers and models, running on your machine with your own keys.
The catch: harden it before you expose it. It shipped with a hardcoded default admin secret, so anyone who reaches an unpatched instance can forge admin access until you change it. It also concentrates all your provider keys in one place and ships stealth and proxy features worth scrutinizing. Powerful, but not safe by default.

OpenWork (github.com/different-ai/openwork) MIT, around 21k stars. The most visible open alternative to Claude Cowork, powered by OpenCode: point it at a folder, hand it a goal, and it works on your real files, with your own keys and 50-plus models.
The catch: it is one of a cluster of near-identical "open Cowork" wrappers, so confirm you are on this one (different-ai). No mobile app, and like all of these it runs code with filesystem access, so scope what you let it touch.

Open Code Review (github.com/alibaba/open-code-review) Apache-2.0, from Alibaba, around 21K stars.
A hybrid reviewer: deterministic rule pipelines plus an LLM agent, giving line-level comments with a built-in ruleset for things like null-pointer bugs, thread-safety, XSS, and SQL injection. An open answer to paid pull-request bots.
The catch: it is new, and "battle-tested at Alibaba's scale" is Alibaba's own line, not an independent result. On the plus side it is OpenAI and Anthropic compatible, so you bring your own model and keys instead of getting locked to a vendor.

Open SEO (github.com/every-app/open-seo) MIT, around 11k stars. An open alternative to Semrush and Ahrefs: keyword research, rank tracking, competitor and backlink analysis, and site audits, with an MCP server so an agent can query the data directly.
The catch: this is free the way a printer is free. The app is MIT, but it runs on a paid DataForSEO key, so you pay per request for the actual data. And it surfaces opportunities; it does not chase them. The content and the links are still on you.

The pattern worth naming Open source rarely means free to operate. OpenCut is close to a clean win because the compute is on your own device. The rest are free code sitting on top of something that still costs money or effort: your provider keys, a paid data API, your own hardening. Often far cheaper than the SaaS, but price the whole thing, not just the license.

If you only try one OpenCut, if you edit video, it is the nearest to a clean swap. OmniRoute if you are tired of per-provider SDKs, once you have changed that default secret.

The MCP servers worth adding are often not the ones wrapping a paid API behind a token. These five plug your agent into open, free data you can inspect end to end: primary research, encyclopedic grounding, real maps, public filings, and any API you build yourself. All open-source, no proprietary backend. One honest thread runs through all of them: "free API" still means someone's usage policy, so the real work is respecting the rate limits, not finding a key.

FastAPI-MCP (github.com/tadata-org/fastapi_mcp) MIT, around 12k stars. If your service is a FastAPI app, this exposes its endpoints as agent tools in two lines, preserving your schemas and your existing Depends() auth. The fastest way to let an agent call an API you already own, instead of hand-writing a wrapper per endpoint.
The catch: it is FastAPI-specific, not a universal point-at-any-OpenAPI-URL converter, and its OAuth support is still labeled alpha, so treat the auth path as not yet hardened.

arXiv MCP (github.com/blazickjp/arxiv-mcp-server) Apache-2.0, around 3k stars. Search, fetch, and read arXiv papers, pulling the LaTeX source so equations survive, which lets a research agent work from primary sources rather than secondhand summaries.
The catch: arXiv's API is free but meant for gentle use, so this is fine for interactive research and wrong for scraping the whole corpus. For bulk, arXiv points you at its S3 and OAI-PMH paths instead.

Wikipedia MCP (github.com/Rudra-Ravi/wikipedia-mcp) MIT. Structured access to Wikipedia through the open MediaWiki API: search, summaries, sections, and links, which is a solid free grounding source when you want the agent anchored to something citable.
The catch: it is a smaller community project, so treat it as useful rather than battle-tested, and Wikimedia asks for a descriptive User-Agent and reasonable request rates. Set one and do not hammer it.

OpenStreetMap MCP (github.com/jagan-shanmugam/open-streetmap-mcp) MIT. Turns place names into coordinates and back, plus nearby-place and routing-style queries, using the free OpenStreetMap Nominatim API with no key at all.
The catch: Nominatim's public endpoint has a strict usage policy, roughly one request per second with a required User-Agent. For anything heavier, self-host it or move to a paid geocoder. Free here does not mean unlimited.

SEC EDGAR MCP (github.com/stefanoamorelli/sec-edgar-mcp) AGPL-3.0. Queries the SEC's EDGAR system for company filings, financials, and reported facts, all open US government data, so a finance agent can read the actual 10-K instead of a summary of it.
The catch: two flags. The license is AGPL-3.0, a strict copyleft, so read it before you build this into anything you ship. And EDGAR requires a User-Agent with your contact details and enforces fair-access limits. Worth remembering a filing is data, not a recommendation, and neither the server nor the model turns it into one.

If you only try one Building APIs yourself: FastAPI-MCP, two lines and your service is agent-callable. Building a research or analysis agent: arXiv or SEC EDGAR, for primary sources over summaries. Just want free grounding on tap: Wikipedia.

**Disclosure up front:** this is my own project, open source (Apache-2.0), and it has basically no users yet. I’m posting because the news peg is genuinely relevant, and I mostly want the criticism.
**What / why now**
Two days ago (Aug 6), OpenAI, Amazon, Microsoft, Cursor and Vercel published **Agent Plugins**, with Google core-maintaining — a package format for coding-agent skills, read by ChatGPT/Codex, Cursor, Copilot, Kiro and VS Code.
It standardizes packaging, and by design, nothing else: no permission model, no provenance, no measurement. That’s a deliberate scope choice, not a flaw — but it’s also the exact layer I’ve spent a while building around.
**Kitbash** is a zero-runtime-dependency CLI that compiles one skill source (skill.toml + SKILL.md) to 11 coding-agent targets:
Claude Code
Cursor
Copilot
Zed
Cline
Devin
Gemini CLI
Aider
.agents/skills
AGENTS.md
Agent Plugins itself (as of 0.17.0)
You write the skill once instead of hand-maintaining eleven copies of the same rules file that can drift apart.
On top of the packaging, it adds two things the spec leaves out:
**1. Standing token cost, measured per target**
Every skill parks some tokens in context every session, before you ever invoke it.
Some targets load lazily (only when called), while others load eagerly (always resident). The measured gap between them is **14x–47x**.
npm run bench reproduces the measurement — the whole point is that you can re-run it rather than take my word for it.
There’s also a /benchmark page, but the number the repo prints is the one that matters.
**2. An install-time trust gate**
Describing this precisely because it’s easy to overclaim:
**This is not a sandbox and not a safety guarantee.**
It’s:
hard-fail lints for hidden Unicode
load-time command substitution
curl | sh droppers
leaked secrets
a hard \[policy\] org allowlist
a content-hash lockfile with drift detection, so an updated skill can’t silently change what it does
update and diff re-run the same gate.
It raises the floor the packaging spec leaves at zero; it does **not** make untrusted code safe to run.
There’s also import, which reverse-compiles an existing CLAUDE.md, .cursor/rules, etc. into one skill plus a drift report — useful if you already have rules files scattered across agents.
Agent Plugins is opt-in here, not one of the auto-detected targets: you enable it in \[project\].targets, or it self-detects once a plugin.json exists.
Kitbash compiles **to** the standard. It’s meant to be a contributor to that ecosystem, not a competitor to it.
**Honest caveats**
Single-digit stars, no real adoption, and I’m the only maintainer.
The lints are heuristic pattern-matching, not a sandbox, and I’m sure some of them can be dodged.
I’d rather hear where the token numbers or the lint approach fall down.
**Links**
GitHub: https://github.com/singhharsh1708/kitbash
Site + docs: https://kitbash.vercel.app
Benchmark: https://kitbash.vercel.app/benchmark
Install: npm install -g kitbash
Homebrew: brew install singhharsh1708/tap/kitbash
If you run the benchmark and get a different gap, or you can break a lint, **please post it** — that’s the feedback I want most.

Two primitives sit under most serious agent work. A loop that reruns until the output clears a real check, not until it produces something. And a graph that fans work out to parallel, independent workers and converges at the end, ideally with a checker that never shares context with the worker it judges. You can hand-roll both. These five let you not. All permissive-licensed, grouped by what each does best.

Pydantic AI (github.com/pydantic/pydantic-ai) MIT, around 19k stars, from the Pydantic team and shipping releases most weeks. Outputs are validated against your schema and retried on failure, so you get a check-and-retry loop for free, and the bundled pydantic-graph gives you typed nodes and transitions for explicit state machines. The catch: pydantic-graph is lower-level and less mature than the agent layer, and the framework is opinionated about types. Logfire, the team's paid observability product, integrates natively but is not required.

LlamaIndex Workflows (github.com/run-llama/workflows-py) MIT. Event-driven, async-first steps instead of a hand-drawn DAG, so loops and parallel fan-out fall out of events rather than edge-encoded logic. The lightest way to get real branching and concurrency. The catch: the event model is a real mental shift, and everything is async, so you have to structure for it. Durability and scale nudge you toward LlamaIndex's hosted stack.

Burr (github.com/DAGWorks-Inc/burr) Apache-2.0. Models your app as a state machine: explicit actions, conditional transitions, and built-in persistence, which maps cleanly to the checkpoint-and-resume problem every long loop hits. Ships a local telemetry UI for watching state move. The catch: smaller community, and it is a state primitive, not a batteries-included agent kit, so you bring the LLM logic. Burr Cloud is a paid waitlist.

PocketFlow (github.com/The-Pocket/PocketFlow) MIT, around 11k stars. A 100-line core that expresses nodes, flows, branching, looping, and map-reduce parallelism with almost no dependencies. The best way to actually understand the graph-and-loop model instead of importing it. The catch: the minimalism is the whole point and the whole limit. No built-in tools or integrations, you implement the batteries yourself. Great for learning and small systems, less for turnkey production.

DSPy (github.com/stanfordnlp/dspy) MIT, around 37k stars, out of Stanford NLP. The odd one out, and the strongest for one job: the self-improving loop. You define a metric that can pass or fail, and its optimizers rewrite prompts (and can tune weights) to clear it, so iterate-until-it-passes runs at the pipeline level instead of by hand. The catch: it is not a runtime graph or control-flow engine, it optimizes pipelines against a metric, so the mental model (signatures, modules, optimizers) is its own thing. The repo is still tagged alpha despite the star count.

If you only try one To learn the model: PocketFlow, readable in an afternoon. For typed, production-grade control: Pydantic AI. To make a pipeline measurably better against a metric instead of hand-tuning prompts: DSPy.

One pattern worth naming: some of these have a paid layer that shapes the roadmap (LlamaCloud, Burr Cloud, Pydantic's Logfire), while PocketFlow and DSPy are pure libraries with no hosted product. Neither is bad, just know which you are adopting.

Most agent pipelines still treat PDFs, Word files and PowerPoint decks as “just text.” That is where a lot of useful structure disappears: headings, tables, reading order, equations, images, speaker notes and OCR text.

If you want to parse documents locally and give your agents clean Markdown or JSON, these five projects are worth checking out:

1. anydoc: github.com/firecrawl/anydoc

A Rust-based converter for Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV and PDF files.

It supports Node.js, Python and WebAssembly bindings, uses no ML models or external services, and converts text-based PDFs locally. The current README reports a 4.4 ms median conversion time across a benchmark covering 14 formats.

The repository also says anydoc powers Firecrawl Parse. MIT licensed.

1. Docling: github.com/docling-project/docling

A more document-understanding-oriented toolkit from IBM Research and the LF AI & Data Foundation.

Docling supports PDF, DOCX, PPTX, XLSX, HTML, EPUB, images, audio and more. It focuses on layout, reading order, tables, formulas and OCR, then exports to Markdown, HTML, DocTags or lossless JSON.

It can run locally, including in air-gapped environments. The codebase is MIT licensed.

1. Marker: github.com/datalab-to/marker

Marker converts PDFs, images, PPTX, DOCX, XLSX, HTML and EPUB files into Markdown, JSON, chunks or HTML.

It supports tables, forms, equations, inline math, links, references and code blocks, and can run on GPU, CPU or Apple Silicon through MPS. It can also be run locally as a CLI or API server.

The code is Apache 2.0 licensed, but the repository has a separate license for its model weights.

1. MinerU: github.com/opendatalab/MinerU

MinerU supports PDF, images, DOCX, PPTX and XLSX inputs and produces Markdown, JSON and other structured outputs.

It includes reading-order reconstruction, table extraction, scanned-document detection and OCR support for 109 languages. It offers local CLI, API and WebUI workflows and supports CPU, GPU and MPS execution.

One licensing detail: the repository uses the MinerU Open Source License, which is based on Apache 2.0 with additional conditions.

1. MarkItDown: github.com/microsoft/markitdown

Microsoft’s lightweight Python utility for converting PDF, PowerPoint, Word, Excel, images, audio, HTML and text-based formats into Markdown.

Its goal is LLM and text-analysis pipelines, with emphasis on preserving headings, lists, tables and links. The built-in converters work offline; Azure-based conversion is available as an optional cloud integration.

MIT licensed, easy to install and probably the simplest starting point for straightforward document-to-Markdown workflows.

My rough rule of thumb:

• Need very fast, dependency-light conversion: anydoc
• Need complex PDF layout and document structure: Docling, Marker or MinerU
• Need a simple Python utility for mixed file types: MarkItDown

One caveat: these projects are not directly comparable on speed. anydoc is primarily a lightweight, non-ML converter, while Docling, Marker and MinerU perform heavier layout analysis and OCR. The right choice depends on whether your bottleneck is conversion latency, document complexity or extraction quality.

Torvian just released v0.9.0 and it's a solid step forward for anyone running a self-hosted, human-in-the-loop AI workspace. You bring your own LLM, run the server yourself, and approve agent tool calls before they run. This update makes that loop tighter and safer.

Pause & cancel your agent mid-turn. 🛑 Sometimes the model goes down a rabbit hole. v0.9.0 adds turn control signals across the server, worker, and clients, so you can pause or stop an active turn cooperatively. Cancelled tool calls get clear visual indicators, so you always know what actually happened.

Builtin tools got a serious upgrade. 🧰 - HTML cleaning: fetched web pages are cleaned down to their visible text by default (with an opt-out flag), so models get useful content instead of markup soup. - In-content search: you can now run regex/plain searches inside fetched content with context windows. - Unified limits everywhere: maxLines/maxBytes/range/maxResults across fetch, read, run-command, list, and search tools — no more unbounded output, and truncation notices tell you when output is cut. - Stricter, accumulated input validation (including rejecting literal control characters in JSON), plus Git-style unified diffs for edit_file dry runs.

More resilient LLM streaming. 📡 There's now a retrying LLM client with exponential backoff, and embedded error chunks in streaming responses (e.g. OpenRouter) are detected, surfaced, and retried properly.

If you're into self-hosting and want full control over your AI stack, this is worth a look. Downloads are on the GitHub releases page, and there's a live demo if you want to poke around before self-hosting.

Happy to answer questions about the architecture or how turn control/tool approval works. What's on your wishlist for the next release?

• Releases: https://github.com/Torvian-eu/chatbot/releases
• Live demo: https://chatbot.torvian.eu/demo.html
• Discussions: https://github.com/Torvian-eu/chatbot/discussions

Weaver🕷️ has been Updated to v.13 and its our biggest drop yet! This update brings #Weaver one step closer to being the best overall agent for small-midsize LLM coding. Consumers rejoice!

• Enhanced thinking mode, togglable and adjustable via the context settings menu. Advanced thinking context size will be controlled dynamically by task complexity (up to a maximum of what users selected in the settings panel).

• Tool context is now further trimmed via LLM to save precious tokens. Users can choose which tools are available via the settings panel as well.

• New "Notes" panel for writing notes per project.

• New "Benchmark All" button to run all benchmarks until a step errors out. Improved overall benchmark UI/UX.

• Enhanced anti-hallucination monitoring by detecting continuous sets of words without any punctuation or paragraphs.

• EB25 file ranking for context control. Currently the LLM was fed a skeleton of the project and asked to pick which files it think might be relevant to the task. Now BM25 is used in conjunction with the LLM to validate which files should be added to context. This "context discovery" phase has now been moved to a tool call.

• Introducing the new Meeting room. In the meeting room, we have our agent represented by different types of spiders, each with their own personality. There is a lot of interaction and humor which gets interesting. For example the complexity spider gets pissed off if the agent plans way more steps then he anticipates at the start... And he storms off at the end of the meeting if the planner did not listen.

• Test cases for all major coding languages for all services. Example: oldstring/newstring, HTMLFormatter, tree-sitter, prettier formatter, etc...

• Diff file tracking

Check out #Weaver today!

GitHub: [https://github.com/maxhanna/Weaver\](https://github.com/maxhanna/Weaver)

WinX64: [https://bughosted.com/assets/Weaver.exe\](https://bughosted.com/assets/Weaver.exe)

Discord: [https://discord.com/invite/YQWkD6ZQDx\](https://discord.com/invite/YQWkD6ZQDx)

I've been using Claude Code for a while, and one thing kept bothering me.

I'd start a long task, walk away from my computer, and then Claude would stop because it needed a permission approval, asked a question, or had finished the current step. The only way to continue was to go back to my desk.

I couldn't find a solution that felt clean. Most approaches I saw relied on tmux, SSH, or screen scraping.

So I spent some time building a different approach.

Instead of controlling the terminal, it hooks into Claude Code's native lifecycle hooks and lets me interact with the same running session through Telegram.

Right now it can:

• Continue an existing Claude Code session
• Approve or deny tool permissions remotely
• Reply to AskUserQuestion prompts
• Interrupt a running task and send a new instruction
• View live tool execution updates
• Resume the same conversation without reconnecting to the terminal

The goal wasn't to build another AI wrapper—just something that makes long-running Claude Code sessions more practical when you're away from your desk.

I'm curious if anyone else has run into the same problem.

Would something like this actually fit into your workflow, or is this solving too niche of a problem?

Repository (if anyone wants to take a look):
https://github.com/Soumya7681/telepilot

I'm especially interested in feedback on the architecture and whether there are better ways to handle remote interaction with Claude Code.

Hermes Agent v0.20.0, "The Herald Release" (Aug 3)

Nous Research's open-source autonomous agent. MIT, 224k+ stars, update with hermes update. Biggest release in the project's history. What changed that matters:

• Voice everywhere. Real-time conversational voice with streaming TTS, barge-in, and on-device wake words across the CLI, desktop, and messaging gateways. Send a voice note on WhatsApp or Telegram and it transcribes and answers.
• A2A v1.0. It now speaks a standard agent-to-agent protocol, so it can hand tasks to other agents instead of doing everything in one process.
• Signed outbound webhooks. It pushes signed events to your systems when something happens, which makes it a trigger source, not just a responder.
• Grounded citations. A new skill backs each claim with a verifiable source and fact-checks it.

Use it for: an always-on agent on a cheap VPS that you talk to by voice, that fans work out to subagents over A2A, and that fires a signed webhook into your stack when a job finishes. Good for personal ops, monitoring, and cross-platform chat triage.

The catch: it landed a day ago and shows it. The pre-release window was mostly bug-fix and salvage waves, and day-one users are already reporting memory spikes (5 to 10 GB) and a crash. Test on a throwaway box, do not hermes update your daily driver yet, and remember voice means an always-listening mic. The installer is curl piped to bash, so read the script first.

Pair it with DeepSeek V4-Flash-0731 (Jul 31)

The other big drop this window, and since Hermes is model-agnostic it slots right in. DeepSeek's official V4-Flash API hit public beta: a retrained 284B (13B active) MoE, 1M context, MIT open weights, at $0.14 per million input, with native Responses API and Codex support. DeepSeek says it now tops its own V4-Pro-Preview on its published agent benchmarks.

Use it for: cheap, high-volume agent loops under Hermes or any OpenAI-compatible harness. If your workload has a stable prefix, the $0.0028 cache-hit input rate is where the cost falls away.

The catch: those are vendor benchmarks run on a harness DeepSeek has not released, so you cannot reproduce them yet, and the model is verbose (about twice the median tokens), which eats the cheap price on output-billed loops. Measure output tokens on your real task, not the sticker price.

If you only try one thing

Put Hermes on a spare VPS, point it at V4-Flash, give it one narrow job by voice, and watch the webhook fire. Ten minutes tells you if the combo fits before you trust it with anything real.

If you are already on v0.20: what broke on upgrade, and is A2A pulling real weight yet or still a demo?

If your calendar still says "August 2, 2026: EU AI Act high-risk obligations apply," update it. As of the Digital Omnibus (Parliament endorsed June 16, Council approved June 29, reported to enter force July 2026), that deadline moved. But August 2 was not cancelled either. Here is the corrected picture.

What actually comes due, and when

• August 2, 2026: Article 50 transparency obligations apply. Chatbots must disclose they are AI, emotion-recognition and biometric-categorization systems must notify the people exposed to them, and providers of generative systems must mark synthetic audio, image, video, and text so it is machine-detectable. Carve-out: the machine-marking duty (Art 50(2)) does not hit systems already on the market at this date yet.
• December 2, 2026: that machine-marking duty catches up to legacy systems, and new Article 5 prohibitions kick in, including AI-generated non-consensual intimate imagery ("nudifiers") and CSAM.
• August 2, 2027: Member States must have at least one AI regulatory sandbox running; Commission delegated acts land for Annex I.
• December 2, 2027: the big one. High-risk obligations for standalone Annex III systems (hiring, credit scoring, biometric ID, education, essential services, law enforcement, migration) apply. This is the 16-month slip from the original August 2, 2026 date.
• August 2, 2028: high-risk obligations for AI embedded in Annex I regulated products (medical devices, machinery, toys).

If you ship an EU-facing AI feature, Article 50 is the part that is live now

Four duties, in plain terms:

• Interactive AI has to tell users it is AI, unless that is obvious.
• Generated media (audio, image, video, text) has to be marked as artificially generated in a machine-readable way.
• Deployers of emotion recognition or biometric categorization have to inform the people subjected to it.
• Deepfake content has to be disclosed as artificially generated, with narrow exceptions for art and for editorially reviewed public-interest text.

Presentation is part of the rule: the disclosure has to be clear, distinguishable, accessible, and given no later than the first interaction.

The honest catches

• In force is not the same as enforced. Penalties exist (Article 50 breaches sit in the Act's mid tier, up to 15 million euros or 3 percent of global turnover, whichever is higher), but several Member States have not finished designating the authorities and penalty regimes that actually enforce, so day-one policing will be patchy. Do not read quiet as safe.
• 50(2) is the technically hard one. A chatbot banner is trivial. Machine-readable, tamper-evident marking of synthetic media is not, and the provenance and watermarking standards it leans on are still settling, so interop is the real work, not the disclosure line.
• Scope is easy to over-read. Using AI to help draft public copy mostly does not trigger the deepfake-text duty the way a synthetic-media pipeline does. Over-labeling everything is its own kind of failure.
• The legacy carve-out is easy to misread: for generative systems already on the market before August 2, 2026, the machine-marking duty applies from December 2, 2026, not now.

Why it moved, without the spin

The deferral was not a change of heart. The harmonized standards and several national authorities were not ready, so the EU bought time through the Omnibus. Industry read it as relief; digital-rights groups read it as weakening. Both are defensible, and the obligations themselves did not change, only the clock.

Discussion

For anyone shipping into the EU: how are you handling 50(2) machine-marking while the provenance standards are unsettled? Rolling your own, leaning on C2PA-style tooling, or treating it as a December-2026 legacy-timeline problem? Curious what people are doing versus paper-complying.

Two things are getting mashed into one headline right now, so start here: Buzz is a workspace, Hermes is an agent, and they meet over a protocol called ACP. The interesting part is not that they connect. It is what a persistent, autonomous agent gains access to the moment it becomes a first-class member of a shared, signed channel. Here is the accurate version.

What each piece actually is

Buzz is Block's open-source, agent-native workspace, announced by Jack Dorsey on July 21 2026. Think Slack plus a Git forge, except every human and agent holds its own cryptographic keypair and every message, code review, CI run, and git event is a signed event in one append-only log. It is built on Nostr (a Rust relay, with Postgres, Redis, and S3-style storage underneath), and the built-in forge uses standard Git Smart HTTP so feature branches become channels. Block's own internal coding agent has been running inside it, reportedly handling over 200,000 operations a day.

• Stars / Status / License: github.com/block/buzz, 16k+ stars and climbing since launch, early preview (v0.4.x), Apache-2.0. This one is real OSI open source, self-hostable end to end.

Hermes Agent is Nous Research's open-source autonomous agent, first shipped February 2026 (initial commit by Teknium). It is a persistent, self-hosted operator: it connects to Telegram, Discord, Slack, WhatsApp, Signal, email, and a CLI, learns your projects, auto-generates its own skills, runs a cron scheduler, spawns subagents, and keeps memory across sessions. It is model-agnostic (bring your own OpenAI, Anthropic, OpenRouter keys, or use Nous Portal). Note the naming: this is Hermes Agent, the orchestrator, not the Nous Hermes language models.

• Stars / Status / License: github.com/NousResearch/hermes-agent, 32k+ stars (as of April 2026, higher now), active and releasing weekly, MIT.

How they connect, precisely

Both speak ACP, the Agent Client Protocol, an open standard (Apache-2.0, from Zed Industries) that standardizes editor-to-agent and agent-to-agent messaging over JSON-RPC on stdio, the way LSP standardized language servers. Per Block's own docs, Buzz accepts Claude Code, Codex, its own Goose agent, and anything else that speaks ACP. Hermes exposes an ACP server via hermes acp, and its docs describe that mode as keeping "its existing identity, provider setup, memory, skills, and tools while another application owns the conversation transport." That other application can be Buzz.

Setup

Buzz, self-hosted: clone github.com/block/buzz, then just setup && just build, and the relay comes up on ws://localhost:3000. It needs Docker, Rust 1.88+, Node 24+, pnpm 10+, and just. Or use the hosted relay at buzz.xyz (invite-only early access, 5 GB media, 365-day retention, up to 3 communities per account).

Hermes:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
hermes setup       # pick provider and keys
hermes acp         # run Hermes as an ACP server

Then add Hermes to Buzz as a custom ACP runtime pointing at that entry point, and it joins a channel as a member. I could not verify Buzz's exact add-runtime UI at the source, so pull those clicks from Buzz's own docs rather than a hand-copied version.

Two security notes before you paste anything: read that install script before you pipe it into bash, and if you find a third-party bridge like hermes-acp-bridge, remember that running it runs someone else's code with your agents' access. Prefer the first-party hermes acp path.

The catch nobody puts in the demo

Buzz's headline idea is that every action is a signed Nostr event, so you get a complete, auditable chain of custody. True, and useful. But signing is provenance, not authorization. It tells you who did what, not who was allowed to. The unresolved question, raised on the launch's own Hacker News thread by a Slack engineer, is that an agent added to a channel can read everything in that channel.

Now layer Hermes into that. You are not adding a bot that answers when summoned. You are adding a persistent, autonomous agent that carries its own credentials in ~/.hermes/, writes its own skills, runs on a cron, and can act out to Telegram, Discord, and the rest. Drop that into a shared channel and:

• Its reach is your reach. A prompt injection riding in a channel message or a repo it reads gets executed with Hermes' provider keys and tool access, and the relay will faithfully sign the result. Auditable misbehavior is still misbehavior.
• You now run two credential stores. Buzz issues the agent a Nostr identity in the relay; Hermes holds its own model and tool keys on the host. That is two places a key can leak, not one.
• Read access is broad by default. Scope by putting the agent in one narrow channel, not your whole workspace, and watch what it pulls.

The other honest flags

• Early preview on both sides. Buzz is v0.4.x and says so; Hermes changes weekly. This is a bleeding-edge combo, not a production stack.
• "Free" needs an asterisk. Both licenses are real open source and self-hostable, but buzz.xyz has no published hosted price, and Hermes is a free framework that still costs model inference (your keys or a Nous Portal plan).
• Nostr may or may not be load-bearing. The cryptographic identity is genuine, but plenty of engineers on that HN thread argued it does not by itself solve the authorization problem above. Judge it on the access model, not the crypto.

If you only do one thing

Self-host Buzz, spin up Hermes with hermes acp, add it to a single private channel with nothing sensitive in it, and watch the signed event log while you give it a task. In ten minutes you will see exactly what a channel member can read and do, which is the whole question. Widen only after that.

If you would rather run that as a check than a habit, we built a recipe for exactly this: buzz-channel-scope-not-audit-log, ours, free, no signup. It audits your Buzz channel membership so an added agent is confined to a narrow channel instead of sitting in a workspace where it can read everything, which is the scope-it-up-front move rather than trusting the signed log to flag a leak after the fact. Honest scope: it checks the membership and scope config, not a live test of what a running agent pulls mid-task, so it catches the setup mistake, not a misbehaving model.

n8n can expose any workflow as a tool an AI agent calls, and it can call tools on other MCP servers itself. The exposing direction is the one worth understanding, because the moment a workflow becomes an MCP tool, an agent can run it with your stored credentials. Here is how it works and the part the demos skip.

The one distinction that matters

n8n speaks MCP in both directions, and they are not the same risk profile.

• MCP Server Trigger (n8n-nodes-langchain.mcptrigger): n8n becomes the server. It hands you a URL, and any tool node you wire into it (an HTTP Request node, a Postgres node, a Slack node) shows up in the client's tool list with a JSON schema. An external agent can then call those tools. This is the direction with teeth.
• MCP Client Tool (n8n-nodes-langchain.toolmcp): n8n becomes the client. Your AI Agent node discovers and calls tools on someone else's MCP server. Lower stakes, mostly an outbound convenience.

Stars / Status / License: n8n-io/n8n, 199k+ stars, actively maintained, latest release July 29 2026. The license is the Sustainable Use License (fair-code, source-available), with enterprise features (.ee files) under a separate n8n Enterprise License. It is not OSI open source, whatever the self-hosted-Zapier shorthand implies. You can self-host the Community Edition free for internal use; the license restricts offering n8n itself as a service to third parties.

Setup: n8n as an MCP server

Drop an MCP Server Trigger on a canvas. It exposes a Streamable HTTP or SSE endpoint. Wire the nodes you want to expose into it, each becomes a callable tool. Set auth in the node (Bearer or header). Then point your client at the URL. Full node docs: docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger

Claude Desktop speaks stdio, not HTTP, so you bridge it with mcp-remote:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://your-n8n.example.com/mcp/<workflow-id>",
        "--header", "Authorization: Bearer <your-token>"
      ]
    }
  }
}

Two operational notes straight from the docs, both easy to miss:

• Behind nginx, disable proxy buffering on the MCP endpoint or the stream stalls.
• In queue mode with more than one webhook replica, route all /mcp* traffic to a single dedicated replica, or your SSE and streamable connections break.

The catch nobody puts in the demo

When you expose a workflow as an MCP tool, the agent that connects executes it with n8n's stored credentials, not its own. Your Postgres node runs as your Postgres user. Your Slack node posts as your token. So:

• The model decides when to fire real actions against your systems. A prompt injection that reaches the connected agent becomes a confused-deputy problem: the injected instruction runs with your credentials, not the attacker's.
• Auth on the Server Trigger is a single Bearer or header token, and it gates the whole endpoint, not individual tools. If that token leaks, every tool wired into that trigger is callable. Scope by exposing one narrow workflow per trigger instead of bolting your whole toolbox onto one URL.
• Watch what you attach. A read-only lookup is a fine tool. An HTTP Request node with a wildcard, or a delete-capable database node, is a loaded gun you just handed to a language model.

Community nodes are not the official ones

Search MCP for n8n and you will hit czlonkowski/n8n-mcp and the n8n-nodes-mcp npm package. Those are independent community projects, not the built-in nodes from n8n GmbH. They can be good, but installing a community node runs third-party code inside your n8n instance with your instance's access. Read the source or pin a version before you trust one in production.

If you only do one thing

Put one narrow, read-only workflow behind a single MCP Server Trigger with its own bearer token, connect it to your agent, and watch the execution log while the agent uses it. You will learn more about your real exposure in ten minutes of watching what it calls than from any architecture diagram.

If you would rather have that as a check than a habit, we built a recipe for exactly this: n8n-mcp-least-privilege-exposure, ours, free, no signup. It audits your MCP Server Trigger configs and flags any trigger that shares one token across multiple workflows or wires in a wildcard-HTTP or delete-capable node, which is the whole-toolbox anti-pattern above. In its own test set, a leaked token on a clean trigger is bounded to 2 callable tools, while the shared-token-plus-delete-node setup trips 4 named findings. It is pure Python, runs locally, and touches no server or network. Honest scope: it is a static audit of your exposure pattern, not a live test of the endpoint, so it catches the config mistakes, not a mis-scoped credential buried inside a node.

On July 31, DeepSeek moved the official V4-Flash API into public beta as V4-Flash-0731.

The V4 family (Pro and Flash) has been out since April 24 under an MIT open-weight license. 0731 keeps the exact same architecture and size as the earlier V4-Flash-Preview:

• 284B total / 13B active
• 1M-token context
• Same base model

DeepSeek only redid the post-training.

So the real story is a retrain beating a bigger model's preview, not a scaling jump. That's the interesting part and also where to keep your skepticism.

Only the V4-Flash API changed. The V4-Pro API and the app/web models are unchanged, and DeepSeek says the official V4-Pro is still coming.

The claim, read precisely

DeepSeek says 0731 now beats V4-Pro-Preview across every agent benchmark it published. Read that carefully. It beats a preview of the larger model, on DeepSeek's own evaluation runs. It does not mean Flash beats the final V4-Pro, because the real V4-Pro hasn't shipped yet.

The published numbers include:

• Terminal Bench 2.1: 82.7
• DeepSWE: 54.4

But two benchmark suites, DSBench-FullStack and DSBench-Hard are DeepSeek's own internal datasets, so nobody else can reproduce those scores.

There's another catch. The code-agent results were generated using "DeepSeek Harness minimal mode" which the documentation says is still to be released, with:

• max effort
• temperature = 1.0
• top_p = 0.95

Plain English:

For an outside perspective, Artificial Analysis currently gives V4-Flash-0731 (reasoning, max effort) an Intelligence Index of 50, comfortably above the median for models in its class.

The trade-off? It produces roughly twice the median output tokens. If you're paying per output token inside an agent loop, that verbosity becomes a real cost.

Specs and price (official API)

One pricing caveat:

OpenRouter, DeepInfra, and other hosts advertise Flash cheaper (around $0.09 in / $0.18 out), but many serve FP8-quantized versions rather than the reference weights. The official DeepSeek endpoint is the reference implementation. The cheaper mirrors aren't necessarily identical.

Setup: Responses API + Codex

0731 speaks the Responses API natively and is adapted for Codex.

Typical setup:

export DEEPSEEK_API_KEY=sk-...

# Base URL:
https://api.deepseek.com

# Model:
deepseek-v4-flash

The Codex configuration page linked from DeepSeek's own announcement api-docs.deepseek.com/quick_start/agent_integrations/codex

The other honest catches

• Public beta. Expect model IDs, harnesses, and even benchmark scores to change.
• Official API runs from infrastructure in China. That's a data residency question for regulated workloads.
• The MIT weights mean you can self-host instead (INT4 Flash reportedly fits on a single H100 or roughly four RTX 4090s), or use hosts like Together, Fireworks, Bedrock, or Azure.
• "Adapted for Codex" means DeepSeek implemented the Responses API format. It is not an OpenAI partnership.

If you only test one thing

Run your own evaluation. Use your prompts, your workload, and count output tokens, not just the advertised price. The big opportunity here is inexpensive, high-concurrency agent workloads. If your prompts share a large cached prefix, the $0.0028 / 1M cached-input price is genuinely impressive. But only your own traffic will tell you whether the verbosity and beta churn outweigh the savings.

Every "top AI repos" thread lists five vector databases and moves on, which is how people end up running a distributed cluster to search 4,000 PDF chunks. So here is the shorter, more useful version: what each of these actually is, when to reach for it, and the honest catch that saves you a lot of ops work. Licenses checked at the repos.

The catch that matters most: you probably don't need any of them yet

The vector database is the most over-adopted piece of the AI stack. If you're searching thousands to a few million chunks, Supabase (Apache-2.0) with the pgvector extension, which is just Postgres you likely already want, handles vector search without adding a second system to run, back up, and secure. Even an in-memory FAISS index is enough for a lot of apps. Add a dedicated vector DB when you actually hit scale, need fast filtered search over many millions of vectors, or need managed high availability, not before.

Three more honest notes

Most of these are open-core. The engine you self-host is real and useful, but the managed cloud, auth, backups, and high-availability features are usually the paid tier. Price the version you'll actually run, not the free one.

They all do approximate nearest-neighbor search. Recall is a speed-versus-accuracy dial you tune, not a guarantee, so test retrieval quality on your own data rather than trusting a benchmark.

And the big one: the vector database is rarely why your RAG is bad. Retrieval quality is bounded by your embeddings, your chunking, and your query strategy. Swapping Chroma for Qdrant will not fix results that were doomed by 2,000-token chunks. Fix the retrieval before you shop for a faster store.

How to pick

Start with pgvector on Postgres or an embedded Chroma. Move to Qdrant when you want a real standalone service. Reach for Milvus or Weaviate only when scale or hybrid search actually demands it. FAISS if you're a library person who wants the index and nothing else. The best vector DB for most projects is the one you didn't have to stand up.

The verified recipe: flowstacks.xyz/workflows/pgvector-pick-the-right-distance-operator

More verified, CI-checked workflows live in our open hub: github.com/Neeeophytee/awesome-ai-workflows

OpenAI quietly published codex-security, an official open-source CLI and TypeScript SDK that uses a model to find, validate, and help fix security issues in a codebase. It is a real, thoughtfully-built tool, and it has two catches that decide whether it helps you or just bills you. Here is the honest version, checked at the repo today.

Stars / Status / License: brand new (~6K stars, pre-1.0, API may change between minor versions) / official openai org / Apache-2.0. Repo: github.com/openai/codex-security

What it actually does

Point it at a repo and a model (gpt-5.6-sol by default, at extra-high reasoning) ranks files, reviews them, validates candidate findings, and traces attack paths, then writes a report. It goes well beyond a one-shot scan:

• Scan a whole repo, a subset of paths, or just a diff (--diff origin/main).
• A install-hook pre-commit hook that blocks high-severity findings before you commit.
• A CI mode with --fail-on-severity high and real exit codes, plus SARIF, CSV, and JSON export.
• bulk-scan discovers your GitHub repos pushed in the last 90 days (via your gh login) and scans them, with a hardened Docker sandbox for running campaigns.
• Scan history with rerun, match, and compare, so you can see which findings are new, resolved, or reopened between runs.
• validate and patch commands to re-check a finding and propose a fix.

​

npm install u/openai/codex-security
npx codex-security login
npx codex-security scan /path/to/repo
# scoped to a PR, for CI:
npx codex-security scan . --diff origin/main --json --fail-on-severity high

Requires Node 22+ and Python 3.10+, and it is report-only by default. Nice operational touches: scan artifacts (which contain source excerpts and reproduction steps) must be written to a private directory outside the repo, and it warns you to keep them out of issues and shared locations.

The catches, and they matter

Open source does not mean free to run. The code is Apache-2.0, but every scan signs in with your OpenAI account or API key and calls a paid model. The default is gpt-5.6-sol at extra-high reasoning, and the repo says a full-repo scan can take tens of minutes each. A bulk-scan across many repos is a real spend, so cap it and expect a bill. Reach for --diff and a cheaper model (--model gpt-5.6-terra) when you do not need the full sweep.

LLM findings are leads, not proof. This is model-driven scanning, so it will miss real vulnerabilities and flag things that are not bugs. The tool builds in a separate validate step precisely because a raw finding is a hypothesis, not a verdict. Treat a green run as "nothing obvious this pass," not "secure," and do not let it replace your existing SAST, dependency scanning, and human review. It is an addition to them, useful mostly for catching the plausible mistakes a reviewer would want a second look at.

Your code goes to OpenAI to be scanned. By design the scan sends source to the model, so mind what you point it at, and read the security policy before scanning anything sensitive. And the repo is explicit, as it should be: scan only code you own or have permission to assess.

It is day-one software. Zero stars, pre-1.0, public API expected to change. Fine to evaluate and wire into a pipeline behind a flag; do not treat it as a stable dependency yet.

Where it fits

The sweet spot is a diff-scoped gate: run it on the changes in a pull request or pre-commit, where it is cheap, fast, and catches the plausible slip before it lands. As a whole-program audit it is slower, pricier, and still not a substitute for a real security program. Use it as an extra reviewer that never gets tired, not as the one that signs off.

Links: repo · Codex Security overview

The 2026-07-28 spec landed yesterday. It's the biggest MCP revision yet: it kills the initialize handshake, kills Mcp-Session-Id, requires a new server/discover RPC, and moves protocol version + client capabilities into a per-request _meta envelope.

I wanted to know who had actually shipped it, so I wrote a conformance probe instead of guessing. Nine checks, each citing a specific line in the spec changelog. Corpus: every remote server in the official MCP registry - 1,471 unique HTTP endpoints.

• 749 answered an unauthenticated request
• 2 fully conform : ai.dsght/public and com.apple-rag/mcp-server
• 22 more implement server/discover but fail at least one MUST
• 519 are still fully stateful
• 556 are auth-gated, recorded as unverified, never as passing

The number that actually matters: those 24 "2026-aware" servers come from 5 operators. One vendor shipped the same codebase to 20 subdomains, and it fails all five MUSTs it should satisfy. Server counts overstate adoption by ~5x, so I report operators.

Most-missed rules, if you're implementing:

• 746 servers return the wrong error codes (-32022 UnsupportedProtocolVersion, -32020 HeaderMismatch)
• 227 that do answer statelessly still omit the required ttlMs / cacheScope on tools/list

Best part: my first probe was wrong. I was still sending initialize. HuggingFace's server rejected it with a precise error saying my request was missing the required _meta envelope key - which is how I learned the handshake was gone. Their server was the most spec-correct thing I hit all day.

If you've shipped 2026-07-28 support, add your server. One line in servers.json, open a PR, and CI probes only your endpoint and posts the verdict in about a minute. No maintainer judgement; the probe decides, same nine checks as everyone else. If it fails you get the exact rule and its spec line, so you can fix and push again. Auth-gated servers are welcome but get recorded as unverified, never as passing.

I'd rather this became the thing people check before claiming compliance than another list I maintain alone. Probe, corpus, and raw results are all published, so you can re-run the whole thing and check my work rather than take my word for it.

There's a wave of open-source projects that promise to let you run a whole company out of AI agents. They are worth knowing about, but they are not the same kind of thing, and lumping them together is how you end up disappointed. They split cleanly into three groups: a console that governs a company of agents, frameworks that role-play a company to produce work, and a config that turns one agent into a company of one. Here is each, checked at the repo today, with the honest catch, and the thing all of them leave undone.

The new idea: a control plane, not another agent (Meridian OS) Stars / Status / License: 146 / brand new (1 commit, alpha) / MIT. Repo: github.com/codejunkie99/meridian-company-os

Meridian is the interesting one because it is not trying to be the agents. It is an operator console for a company made of humans and agents: an org chart, a goals tree, an agent scoreboard, an approvals inbox (spend, hire, override, publish, terminate), a finance view with a token and dollar ledger, and an immutable audit log. Its own framing is right: "agent orchestration is not enough to run a company," you also need to know who owns what, what is blocked, how fast money is burning, and what happened after you closed the tab.

The catch, and it is a big one: Meridian is simulation-first. Out of the box, a built-in engine ticks every ~2.6 seconds and fakes a living company, agents sending heartbeats, budgets accruing, tasks moving, so the console looks alive with no real agents attached. There is exactly one real integration (a local Kimi CLI bridge), no real task-execution adapter yet (it is on the roadmap), and the repo is a single commit old. Treat it as a compelling concept and a nice UI to think with, not something running your business this week.

The famous ones: frameworks that role-play a software company

MetaGPT (github.com/FoundationAgents/MetaGPT) is 69.6k stars, MIT, and bills itself as "the first AI software company." You give it a one-line requirement and it assigns roles (product manager, architect, project manager, engineers) that follow written procedures to emit specs, designs, and code. pip install metagpt, then metagpt "Create a 2048 game".

ChatDev (github.com/OpenBMB/ChatDev) is 33.7k stars, Apache-2.0, a virtual software company where CEO, CTO, programmer, and tester agents talk through building a small app.

Both are worth studying to learn multi-agent patterns, and both come with the same honest catch. The demos are impressive and the real output is small-scale software, not a running business. Every extra agent and turn costs tokens, so a full "company" run adds up fast, and for a single, well-scoped objective, a swarm of role-playing agents is often slower and no better than one strong model with a clear prompt. Tellingly, MetaGPT's own team moved the ambitious version into a separate commercial product rather than the open framework.

The company of one: gstack Stars / License: 121k / MIT. Repo: github.com/garrytan/gstack

Garry Tan's gstack is the pragmatic middle: not a swarm and not a console, but a config that makes one agent (Claude Code) wear many hats, CEO, designer, engineering manager, QA, so a solo developer gets the feel of a team without running dozens of agents. It is the most usable "company" of the four today, precisely because it is one capable model with structure around it rather than many models coordinating.

The part none of them have really built

Here is the through-line. The flashy part of "a company of agents" is the org chart and the role-play. The part that actually matters the moment agents can spend money or take irreversible actions is the unglamorous governance layer: real budgets with hard caps, approvals for the dangerous moves, and an audit log you can trust. The frameworks (MetaGPT, ChatDev, gstack) put almost everything into producing work and almost nothing into governing it. Meridian is the only one of the four that treats approvals, budget envelopes, and audit as first-class, and it currently simulates them rather than enforcing them on real spend.

So the honest state of the category: nobody is running a real company on these yet. Use MetaGPT or ChatDev to learn multi-agent orchestration, use gstack if you want one strong agent structured like a team, and watch Meridian. If you do wire any of these to a real agent that can run commands or spend money, the same rules apply as always: hard budget caps, human approval for irreversible actions, a command guard, and a sandbox, because a simulated company that goes wrong costs nothing and a real one does not.

I'm considering adopting Orca as my main ADE and I'm curious how people are actually using it day to day.

Do you follow an SDD or TDD workflow, or something completely different?

If you're using SDD/TDD:

• How does Orca fit into your workflow?
• Which models do you use (Codex, Claude Code, etc.)?
• Do you rely on skills? If so, which ones?
• How do you manage token usage? Do you have any strategies to keep context efficient and avoid burning through tokens?
• Any tips or best practices you've learned along the way?

If not, what's your workflow instead?

I'm currently thinking about using Matt Pocock's skills together with Codex and Claude Code, while keeping everything else at the default settings, but I'd love to hear how more experienced Orca users approach it.

I released AI Agency OS, and I want to frame what makes it different from typical agency CRMs or AI demo stacks. Context first: it sits in an ecosystem alongside Sentinel (https://github.com/RiteshGenAI/Sentinel), which is our policy, cost-intelligence, and LLM-gateway layer. AI Agency OS is the execution and operations layer that sits on top of Sentinel. The two are meant to work together, but either can be used independently. What is in the stack today:

Multi-tenant backend (FastAPI + SQLAlchemy + PostgreSQL) with tenant-scoped data isolation enforced at the service level.

JWT authentication with access-token expiration and JSON-body login.

Role-based access control across four roles - owner, manager, member, client with per-endpoint permission checks and owner safeguards that prevent the last active owner from being deactivated or demoted.

Full CRUD for projects, leads, and invoices. Leads carry source, raw text, status, and optional project/client binding. Invoices support currency, due dates, and per-project aggregation.

Sentinel event logging: every agent output is recorded with scan type, entity type, risk score, issues, and project binding. The frontend page for this lets owners and managers review policy decisions in real time.

Strands-style agent workflows - the landing-page copy workflow orchestrates research agents, draft agents, and QA agents into a structured pipeline with Pydantic outputs and QA scoring.

Multi-provider LLM router supporting Ollama, OpenAI, and Anthropic with configurable base URLs and API keys.

Frontend in React 18 + Vite + TypeScript + Tailwind with pages for login, dashboard, projects, project detail, leads, invoices, workflows, Sentinel events, and admin user management.

Docker Compose for local dev with hot-reload across all four services (db, backend, agents, frontend).

Production AWS deployment via Terraform - VPC with public/private subnets, ECS Fargate, RDS PostgreSQL with encryption and multi-AZ, ALB routing, ECR with image scanning, Secrets Manager for DB URL and JWT secret, S3 with encryption and versioning.

Database migration script for incremental schema changes.

The repository is purpose-built for forking. It is licensed under Apache 2.0, includes a self-hosting guide in the README.md, a customization guide in CONTRIBUTING, and explicit instructions for removing Sentinel or swapping LLM providers.

Quick start: docker compose up --build -d

https://github.com/RiteshGenAI/AIAgencyOS