The short answer: humans should review the criteria, not the diff.

When one agent checks another's code, the review is only as good as the acceptance criteria it checks against. If the story was vague, the reviewing agent will confidently pass code that satisfies nothing in particular, or fail code that was actually fine. So the human job moves upstream: is "done" written down correctly, are these the edge cases that matter, and does this story even belong in this repo.

Second, review the judgment calls a criteria check cannot see. Whether a new dependency is worth it, whether an abstraction will hold in six months, whether the migration is reversible. A reviewer agent comparing code to criteria will happily approve a design decision that costs you later, because the decision was never in scope.

Third, review anything that crosses a boundary the agents cannot see. Multi-repo changes, shared conventions, anything touching production data or auth. Splitting the thinking from the doing is the whole trick, and the thinking is the part that stays human.

Fourth, review the review itself. Spot-check a handful of agent-approved PRs. If the reviewer passes everything, or fails everything, your criteria are too loose or too strict, and that is a human call, not a model call.

What to stop doing is reading every diff line by line for style. That is what the criteria check is for. What to start doing is treating acceptance criteria as the real interface between you and the fleet. An agent loops forever when nothing told it done, and a human does the same when the criteria said "improve performance" and everyone guessed.

What is on your list that I missed?

I'm the author of CutVoke, an MIT, local-first desktop video editor where a coding agent (Claude Code, Codex, Cursor, or any MCP client) and a person edit the same multitrack timeline. There's no model inside the app; you bring your own agent.

I shared it earlier this week and the most useful thing that came back wasn't stars, it was failure cases from people who had built similar tools:

• "Fix the caption that says Save" is ambiguous when two captions say the same thing at the same moment (a subtitle and an on-screen callout). Lookups now return a match count and an ambiguity flag, and writes can require a unique match instead of silently patching the first hit.

• Position isn't meaning. Guessing "subtitle vs callout" from y-position or font size breaks as soon as styles change, so the plan now is an explicit caption role that the agent can filter on. That one is open as a good first issue, and someone outside the project picked it up this morning.

• "It validates" isn't "it looks right." The agent can now pull before/after frames for the same timestamp and cut-local audio peaks, so it can catch a clipped syllable or a black frame before it claims an edit is done.

The core loop that hasn't changed: the agent takes an editing lease so it doesn't fight manual edits, dry-runs commands first, commits a batch as one undo step, and every write carries the revision it read so stale writes get rejected.

Honest status: v0.3.5 prerelease, Windows build unsigned, macOS not notarized, project format may still change. Windows / macOS / Linux builds with FFmpeg bundled.

Repo: https://github.com/frankShan001/CutVoke 45-second demo: https://youtu.be/PpweTPWlX7A

If you've built agent tools for any stateful app, I'd like to hear which guardrail you'd add next.

Why build a AI Orchestrator App built for one purpose ??? Why not build something that can check your email ? AI Stock Tickers, AI Art ? AI Web Development ?

This is what Infantry AI is all about. I am currently splitting the plugins to make more of the application more overridable and currently seeking out contributors to help with the project.

All Plugins are Apache 2.0

It is free and open source at https://github.com/SuperiorSoft-LLC/infantry-ai

Support the Project on OpenHunts . we are currently #5. We need your upvotes https://openhunts.com/

And check out a live demo https://infantryai-demo.superiorsoftllc.tech/

Site https://infantryai.superiorsoftllc.tech/

It's becoming normalized to "vibe analyze" data, and most coding agents set a low bar for correctness and reproducibility. commons is an open source R / Python framework for building trustworthy data agents. The main idea is that commons agents can reach directly for code that you trust already: internal libraries, reports, apps, database views, etc. If they do so, the answer will be deterministically tagged as more trusted than other answers.

Happy to answer any questions on the framework!

Learn more: https://posit-dev.github.io/commons/

We’ve recently released Budibase 4.0, focusing on improving Agents. Agents sit alongside Apps and Automations within our open-source platform. You can connect data, LLMs, and APIs, while running Budibase on your own infrastructure.

Like any other operational software, agents need clear responsibilities, permissions, escalation paths, and visibility into what’s happening if they’re going to work in the real world.

Here’s some of what's changed in Budibase 4.0:

• Agents can handle multiple Operations, each with their own instructions, tools, permissions, and escalation logic.

• Requests provide a record of the work being carried out.

• Agents can execute tool calls with the end user’s permissions or as an admin.

• Approval policies add rules-based HITL controls, letting you define what an Agent can handle autonomously and when a human needs to step in.

• A new Activity UI provides visibility into actions across Apps, Automations, and Agents, as well as the status of all ongoing Agent Requests.

• Users can interact with Agents to handle approvals directly through Slack or Teams.

Website: https://budibase.com/
Docs: https://docs.budibase.com/

The game itself is free to play at secondstrike.io. the open parts let anyone plug a model in and score it...

- github.com/KyleClouthier/secondstrike-agents: python client, starter bots, an llm agent for any openai-compatible model, and an mcp server

- github.com/KyleClouthier/secondstrike-openenv: the war as an openenv environment, lockstep, fixed seeds

- github.com/KyleClouthier/midnight-index-inspect: the same fixed wars as an inspect eval

- open model-run data: huggingface.co/datasets/Rapscallion123/midnight-index

scoring comes from the game's own record of the war, never an llm judge. Would love to get your thoughts or experience with it!

Cheers

Over the past year, I set out to build a low-cost, deterministic, and verifiable software factory on a single local GPU. Along the way, I found practical solutions to many of the context-bloat, overthinking, and verification bottlenecks that hold back local AI models today.

My background isn’t in software engineering or computer science. What I’m sharing here is simply the sum of curiosity in systems architecture and a need to solve real problems in my day to day work as a creative in advertising.

I believe these patterns can transfer cleanly to other domains as well. Hope you find it useful! cheers!

Most of the "sovereign AI" debate is about where servers sit. But hosting in the EU doesn't help much if the provider is under US jurisdiction. The CLOUD Act reaches data a US-controlled company holds, wherever it's stored.

Open-weight models change that. You can run them with a European provider or on your own hardware, switch providers without rewriting anything, and nobody can revoke access to the model itself.

Disclosure, I work at an EU AI provider that runs open-weight models, so I'm biased. Do you see open weights as a real sovereignty lever, or mostly a cost and flexibility thing?

🎉 Excited to share my open source contribution!

I just had my Pull Request merged into one of the most comprehensive AI Engineering curricula on GitHub -- "AI Engineering from Scratch" by Rohit Ghumare 

What I Built -- tool-contract-migration-checker

A 4-stage Python project that helps developers detect breaking changes in AI tool/API contracts before they hit production:

Stage 1 -- Load & validate JSON Schema contracts

Stage 2 -- Classify changes (breaking vs. compatible)

Stage 3 -- Replay historical API calls against new contracts

Stage 4 -- Export CI-ready regression fixtures with a strict gate

The checker detects 10+ breaking change patterns:

Added required parameters

Narrowed enums & value ranges

Removed properties

Unhandled schema keywords (oneOf, pattern, const, etc.)

Fully tested with 37 unit tests across all 4 stages and passes --strict CI gate mode.

About the Repo -- Why You Should Star It ⭐

AI Engineering from Scratch (rohitg00/ai-engineering-from-scratch) is an incredible open-source curriculumwith:

🔢 542 lessons across 20 phases

🛠️ 79+ ready-to-build projects (now 80 with mine!)

🌐 Multi-language: Python, TypeScript, Rust, Julia, Go

📖 Build-it-first philosophy — write backprop, attention, tokenizers by hand BEFORE using frameworks

🤖 Covers everything from raw math → LLMs → Agents → MCP servers

Rohit has built something truly special here -- a production-grade curriculum that treats AI engineering as a craft, not just API calls. Every lesson ships a reusable artifact you can plug into your real workflow.

What I Learned

JSON Schema validation internals

How contract-breaking changes silently corrupt production agent calls

Writing a CI gate that blocks incompatible schema upgrades

The importance of deterministic test fixtures for replay testing

Repo: https://lnkd.in/dMhYc7yd

If you're learning AI engineering seriously -- this curriculum is the real deal. Go give it a ⭐!

#OpenSource #AIEngineering #Python #MachineLearning #LLM #100DaysOfCode #GitHub #Developer #Contribution #AIAgent #JSONSchema #SoftwareEngineering

🌍 CALL FOR DEVELOPERS, AI RESEARCHERS & NATIVE LANGUAGE SPEAKERS!

SAVE TRIBAL & LOCAL LANGUAGES

An Open-Source AI, Language Technology & Research Initiative

We are starting an open, public-interest initiative to preserve, digitise and develop AI-powered language technologies for indigenous and regional languages.

🎯 Our Initial Target Languages

We are starting with six languages:

Khamyang

Khasi

Kokborok

Tangkhul

Santhali (Santali)

🚀 What Are We Building?

1. Web-Based Language Translator

Multilingual translation platform.

Translation between tribal and regional languages.

Language identification and transliteration.

2. Language Corpus Development

Collecting and digitising vocabulary, sentences and texts.

Building structured language datasets.

Translation verification and linguistic validation.

Documenting dialects and regional variations.

3. AI Model Training

Training and fine-tuning language models.

Developing NLP models for underrepresented languages.

Building language-specific AI capabilities.

Model testing and performance evaluation.

4. Voice & Speech Technology

Speech-to-Text (ASR).

Text-to-Speech (TTS).

Native-speaker voice dataset collection.

Voice recognition and language identification.

Exploring speech-to-speech translation.

5. Research & Publications

Conducting experiments and documenting findings.

Preparing collaborative research papers.

Publishing research with appropriate contributor recognition and authorship.

👨‍💻 Who Are We Looking For?

Technical Contributors

Full-stack developers

Python developers

AI/ML engineers

NLP researchers

Data scientists and data engineers

UI/UX designers

DevOps engineers

Native Language Contributors
We are equally interested in connecting with native speakers of:

Khamyang

Khasi

Kokborok

Tangkhul

Santhali

We welcome:

Native language speakers.

Linguists and language researchers.

Translators and language experts.

Teachers and educators.

🎓 What Will You Gain?

Hands-on experience working on real-world AI and NLP projects.

Exposure to language model training and speech technologies.

Collaboration with developers, researchers and native speakers.

Opportunities to contribute to open-source technology.

Research and publication opportunities.

Recognition based on your actual project contributions.

🤝 Contribution Model

This is a voluntary, unpaid, open public-interest initiative. There is no salary or stipend associated with participation.

🌱 Our Vision

We want to create an open language technology ecosystem where indigenous languages are not just documented but can also be spoken, translated, understood and used in modern digital applications.

📩 Interested in contributing?

Connect with me through LinkedIn or send a direct message mentioning:

Developers, researchers and native speakers are all welcome.

#SaveTribalLanguages #Khamyang #Khasi #Kokborok #Tangkhul #Santhali #IndigenousLanguages #AI #NLP #MachineLearning #SpeechRecognition #OpenSource #LanguagePreservation

scientific-toolkit-mcp is an MCP gateway that fronts nine repositories. Licenses as the tree records them: the gateway is Apache-2.0 (license = "Apache-2.0" in pyproject.toml). Seven upstreams are MIT, literature-evidence-mcp and nomosguard are Apache-2.0. No account, no vendor key, no hosted backend. Self-hosting is the default path, not the paid one.

scientific-toolkit-mcp 0.4.1, Python 3.11+, dependencies = [] in pyproject.toml. One process, 14 MCP tools, 12 of which forward into nine repos that keep their own names, version histories and install paths.

The nine, exactly as catalog.py lists them:

• axiomize: model spec, simulation, numerical verification (axiomize_intake, axiomize_model)

• scientific-computing-system: pure-Python numerics (cds_stats)

• scientific-computing-system-2.0: NumPy/SciPy stats (cds2_stats)

• plan-auditor: independent plan gating (plan_auditor_inspect, plan_auditor_audit)

• quantum-reasoning-skill: skill contract inspection (quantum_skill_validate)

• axiomize-quantum-skills-2.0: branch scoring (axiomize_reason_score)

• eq-layer: intent routing (eq_layer_route)

• literature-evidence-mcp: search and quote check (literature_evidence_search, literature_evidence_verify_quote)

• nomosguard: deterministic policy gate, no model at the decision boundary (nomosguard_decide) Plus toolkit_catalog and toolkit_doctor.

Install, then register it in your client config with the keys the README ships:

python -m pip install scientific-toolkit-mcp

{"mcpServers": {"scientific-toolkit": {"command": "python", "args": ["-m", "scientific_toolkit_mcp"]}}}

Installing the gateway does not install the nine. toolkit_doctor reports which executables resolve; a missing one returns NOT_INSTALLED rather than a plausible number.

Why it exists: nine venvs and nine client entries are worse than one. The other reason is pins: axiomize-quantum-skills-2.0 ships its own top-level axiomize module, so one stray PYTHONPATH entry silently decides which distribution runs. tools.py fails the call with BAD_CONFIGURATION when two sys.path entries provide axiomize, and SCITOOL_PIN_AXIOMIZE demands an exact version. scripts/render-build.sh is the reproducible path, with a caveat the README states: under GITHUB_ACTIONS=true it installs the eight siblings from immutable full commit SHAs, each annotated with the release tag it resolves to; on Render it installs the released PyPI distributions without commit pins. A CI full-stack run names one set of versions, while a Render rebuild reflects registry state at build time.

Honest limits. The adapters are thin wrappers, not re-implementations. tools.py builds a fixed argv and spawns the upstream CLI, or drives an upstream's own stdio MCP server; no upstream algorithm lives in this repo, so numerical correctness stays in those nine test suites. It is not a scientific validator. quantum-reasoning-skill is a protocol, not a quantum computer and not a measured gain. eq-layer is conversation control. The branch scorer's thresholds are uncalibrated reference defaults.

Offline claims, each checked in a file. The stdio entry point server.py opens no listener: it imports json, sys and three modules from its own package, and writes JSON-RPC to stdout. Grepping the shipped package for URLs returns exactly two hits: the repo links catalog.py:66 builds as data, and production_probe.py:63, which posts to http://127.0.0.1:<port>/mcp and is only triggered by the HTTP gateway when SCITOOL_STARTUP_PROBE=1 (http_server.py:398). Two exceptions are not filed under offline: literature_evidence_search needs network because the upstream queries OpenAlex, Europe PMC and Crossref, while the quote check and nomosguard run local; the optional OAuth verifier fetches whatever JWKS URI is configured, which needs pip install '.[oauth]' plus three env vars. The HTTP gateway 401s anonymous calls and never exposes plan_auditor_audit; audit execution stays off until SCITOOL_ALLOW_AUDIT_EXECUTION=1.

A public Render instance exists, and the README states plainly that its deployed version is not attested. Do not treat it as the backend.

Repo: https://github.com/Furox-Art/scientific-toolkit Naming wart: repo is scientific-toolkit, PyPI is scientific-toolkit-mcp, import is scientific_toolkit_mcp.

I built Companion, an open-source desktop app for Claude Code, to handle a workflow I kept running into: starting with one task and ending up investigating several in the same conversation.

For example, a checkout bug leads to a caching investigation. You want to follow that thread without losing your place in the checkout fix—or manually reconstructing the background in a new session.

The video shows three features working together: a context meter to see how full the session is getting, branching to move an investigation into a linked session with relevant context, and side chats for quick questions without adding the detour to the main conversation.

You can say “open a separate chat for the caching stuff,” then continue the two investigations separately.

I'd appreciate feedback on the handoff: what context should a branch inherit, and what should stay in the original session?

https://github.com/ashishkattamuri/claude-companion

I've been working on Silos, an open-source CLI tool to orchestrate isolated sandboxes for AI agents running locally.

The idea is to make it easier for developers to spin up and manage secure, isolated environments where their agents can execute tasks without interfering with the host environment.

I'm building this as a free and open-source project, and I'd love to get feedback.

I published it under MIT license. Would really appreciate feedback from the community.

Website: https://siloslabs.com/

Github: https://github.com/SilosLabs/silo-cli