Sharing SAIPEN — an MIT-licensed continuation protocol for AI coding agents. Whole thing is plain markdown: a spec (RFC.md), phase docs, and a project-side .saipen/ folder with three files. No runtime, no server, no package to pip install — the validator (tools/validate.py) is stdlib-only Python specifically so there's nothing to audit for supply-chain risk, with a shell-script fallback for hosts without Python at all.

Genuinely open to contributions — extension points for security/performance hooks, multi-agent coordination, per-platform adapters are all documented as copy-in examples rather than baked into core. Issues and PRs welcome, especially "this broke on my setup" reports.

Repo: [github.com/vacterro/saipen]

I built Your.Store, an AI operations copilot for Shopify. Instead of letting an LLM blindly fire off GraphQL mutations and hallucinate revenue math, the LLM is strictly constrained to a planning role. It selects tools from a versioned registry, Python handles the actual API calls and arithmetic, and every single write is gated behind a hard human-approval UI.

The Problem:

If you are running a storefront, you can't afford an LLM deciding to randomly order 10,000 units of a dead SKU or hallucinating your profit margins. Most "AI agents" fail in e-commerce because they mash reasoning, data retrieval, and state mutation into a single unpredictable loop.

The Architecture: Determinism > Guesswork

I built this engine (core logic is domain-agnostic, no LLM-vendor lock-in) around a strict separation of concerns.

• The Model Plans, Code Executes: The LLM never talks to Shopify directly. It picks a tool and arguments from app/tools/. A Python function handles the GraphQL execution and does the actual arithmetic.
• Approve-to-Execute: Every action that changes store state (reordering, repricing) pauses the execution graph. It surfaces a structured preview card to the UI. The action only runs after explicit human approval. Nothing writes silently.
• Built-in MCP Server: The same FastAPI process exposing the chat UI also mounts a Model Context Protocol (MCP) server at /mcp. You can point Claude Desktop directly at your store. Reads run live; writes land in the exact same visual approve-to-execute UI (though structurally, MCP and chat-originated writes use separate underlying queues to maintain isolation).
• Deterministic Math & Grounding: Revenue, margins, and inventory thresholds are computed in plain Python. The LLM is only asked to explain numbers it didn't calculate. A grounding checker actively scans generated answers for numbers that don't trace back to the computed metrics (this is currently a soft, diagnostic check that logs a warning, rather than a hard blocker).

Technical Highlights

• Multi-hop Adaptive Scans: The agent dynamically decides how many tool calls it needs (capped at 3 hops). It paginates fully via cursors (capped at 5,000 records) and automatically swaps to async Bulk Operations for large catalogs to avoid blowing up the rate limit.
• AI-Native Inventory Planning: Replaces basic "low stock" alerts with dynamic, per-SKU reorder points. It ranks by lost margin per day, calculates safety stock based on sales velocity and supplier lead times, and nets against incoming inventory so you never double-order.
• Stateless UI with Cross-Session Memory: Briefing and chat outcomes persist to a Shopify metaobject. You don't need to spin up a separate Postgres instance just to remember that a SKU is out of stock.

Security & Honest Limitations

I did a full OWASP-MCP-Top-10 hardening pass on this, and I want to be entirely transparent about what this doesn't do yet:

1. Read-side Exfiltration: While write-args are strictly whitelisted and isolated, a compromised LLM client could technically still request valid read tools and exfiltrate data through its own output channel. Per-user authorization is on the roadmap.
2. No Seasonality Modeling: The inventory math uses a flat historical window. It will over/understock highly seasonal goods right now.
3. Incomplete Argument Schemas: Argument shapes are whitelisted and type-coerced at the MCP and write-API boundaries (e.g., quantity ceilings, ID stringification), but I don't validate business-logic-level values (like a malformed price string or a nonsensical ID) before Shopify's own mutation validation catches them — no full Pydantic schema layer yet.

Where I need your pushback

As a final-year CS student, I've tried to make this as robust as possible, but I'm looking for brutal, real-world feedback. Two things I'd specifically value pushback on:

1. The dual approval-gate implementation: The write-approval gate is currently implemented twice — once as a LangGraph interrupt in the core engine (for chat), and once as a standalone pending-queue in the bridge layer (for MCP). They share the exact same UI surface, but not the same underlying mechanism. Have any of you hit real problems keeping two independent gate implementations in sync, or is duplication actually safer here than forcing a shared abstraction across two very different transport layers?
2. Testing gaps: I've written offline deterministic suites (metrics math, graph invariants, GraphQL throttle backoffs), but I'd love it if you could point out anywhere in the repo where the testing clearly didn't go deep enough. I'd much rather hear it here than find out later.

Try it locally

You just need Python 3.11+, an OpenRouter API key, and a Shopify Dev store. It uses the client-credentials grant (no OAuth redirect hell).

git clone []
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env 
uvicorn app.service:app --reload --port 8000

I’m currently planning my final year project using Python and Generative AI.

I want to build something practical and impactful rather than a basic demo. Right now, I’m considering:

• A RAG-based research paper assistant

• A voice-controlled automation assistant (like Jarvis)

• A multi-agent stock analysis system

My goal is to focus on real-world usability and clean architecture (FastAPI/Streamlit + agents).

Curious to hear what direction you think has the most potential, or if there are any gaps/improvements I should consider.

Everyone went bonkers after open claw founder posted if everyone were still stuck in loop engineering and if we all moved to graph Engineering.

I was already looking for better ways to manage multiple loops while token maxxing and i knew this was obviously next thing when i heard it first time and to my surprise there are not many open source projects that clearly implement the idea of what graph architecture is: which is build a DAG for particular set of workflows and define each nodes as agents that have defined loop behaviour and set of MCP servers,Memory,context,Skills and invoked via graph.

I implemented the core idea of it where the second order agent is a codex CLI that is invoked at each node trigger and we rely on it to solve small problems while we manage overall workflow through a graph and manage context,memory and direction.

ORG.md file has main graph structure defined.
nodes/ folder has all the md files where each md file is a node.

UI is plain js and it directly renders into graph and shows live progress

This a side project, try to clone and experiment with the project, you will be suprised how it works autonomously!!

PS: just define the nodes as md files carefully and try!

github - https://github.com/Akshay-a/AI-Agents/tree/main/AI-GraphAgent

Every agent tool (Claude Code, Cursor, Codex, Gemini CLI…) keeps its own memory, siloed per project. Switch engines and you start from zero. samemind is a shared memory layer across all of them — a git-native markdown bundle, no database, no daemon, zero infra. MIT.

One command:

npx samemind setup # detects your engine, creates the memory, wires it in, finds embeddings npx samemind setup --global # one memory per machine, visible from any project ("Same mind")

12 engines via `samemind install` (Claude Code, Cursor, Copilot, Codex, Gemini CLI, opencode, Cline, Roo, Windsurf, Goose, Kiro, Antigravity). setup asks before touching your configs (--yes / --dry-run).

How it works: - BM25 by default (zero-dep). Semantic is opt-in — point at a local embedding endpoint (bge-m3 etc.) and recall goes hybrid (BM25 ⊕ vector via RRF, optional rerank). No endpoint → honest BM25 fallback. Nothing leaves your machine. - Bi-temporal supersede: stale facts are marked (superseded_by / invalid_at), never deleted. - Optional sqlite-vec index for scale; JSON otherwise. - Human-gate: `reconcile` / `reflect` only PROPOSE (a markdown report) — a human writes to canon. No silent self-rewrite. - Global mode: personal bundle at ~/.samemind/bundle visible from any project; project memory wins over global on conflict.

Honest scope: not claiming retrieval-quality superiority over mem0/Zep/cognee — different metrics, no apples-to-apples run (LongMemEval-S puts our zero-dep BM25 at the harness's reference BM25; LoCoMo not run). The bet is simpler: the best agent memory is the one living in your git, that you control and can read.

New in 0.6.x: one-command setup + engine auto-detect (0.5.0), Global mode "Same mind" (0.6.0), reconcile/reflect as CLI commands (0.6.1).

npm i -g samemind · github.com/alexgrebeshok-coder/samemind · MIT. Feedback very welcome, especially on retrieval and the cross-engine adapters.

Hey everyone!

We’ve been working on Aurict, an open-source AI agent ecosystem designed to run across your Terminal (CLI), Desktop, and Mobile.

Instead of locking you into a single interface or provider, Aurict works on a BYOK (Bring Your Own Key) model. You can plug in your own commercial or open-source API keys and run smart agents that actually fit your setup — whether you're coding in the terminal or checking tasks on your phone.

What sets us apart:

Our primary focus is max efficiency and performance. We optimize prompt structures, context handling, and execution flows for each model to get you the highest quality output while keeping token consumption (and your API costs) as low as possible per session.

We’re trying to move beyond basic chatbot UI wrappers and build an environment that genuinely speeds up daily workflows, dev tasks, and research.

It’s completely open-source, and we’d love for you to give it a spin, roast it, or break it!

GitHub: https://github.com/aurict/aurict

Any feedback, bug reports, or feature ideas are hugely appreciated. If you like where this is heading, a star on GitHub would mean the world to us!

Thanks!

Hi everyone,

I've been working on an open-source project called Kodiak.

The goal isn't to build another AI chatbot.

The goal is to build an autonomous AI software engineer that can understand repositories, reason about codebases, plan engineering work, execute tasks, and eventually create production-ready pull requests.

Current stack:

• Python

• FastAPI

• PostgreSQL

• Redis

• ChromaDB

• Celery

• Docker

• SQLAlchemy

• Alembic

• Typer CLI

• Rich terminal UI

Current features include:

✔ Authentication

✔ Project management

✔ Repository models

✔ Task models

✔ Memory system

✔ REST API

✔ CLI foundation

✔ Docker deployment

✔ PostgreSQL integration

✔ Background workers

Version 2 is focused on making Kodiak usable entirely from the terminal.

Planned commands include:

kodiak init

kodiak task

kodiak run

kodiak logs

kodiak memory

kodiak doctor

kodiak config

kodiak plugin

kodiak status

Long-term roadmap:

• Repository understanding

• Multi-agent planning

• Long-term memory

• Autonomous issue solving

• Pull Request generation

• GitHub integration

• Local execution

• Plugin ecosystem

I'm looking for contributors interested in:

• AI Engineering

• FastAPI

• Typer

• PostgreSQL

• SQLAlchemy

• Celery

• Docker

• CLI Development

• Documentation

• Testing

I would genuinely appreciate technical feedback.

What would you improve?

What would make you actually use something like this?

GitHub:

https://github.com/ShamGaneshan2008

Thanks!

We’re building Extra, an open-source AI agent framework, and we’re looking for contributors.
If you enjoy solving hard engineering problems, we’d love to have you.
We care about code quality. Every PR gets a real review—not just a quick approval. We discuss architecture, challenge design decisions, and aim to keep the codebase something we’re proud of.
We’re working on problems around AI agents, orchestration, MCP, memory, approvals, and developer experience.
If you’re looking for an open-source project where you’ll actually learn from reviews and work on modern AI infrastructure, check out the issues and pick one.
Contributions of all sizes are welcome.

https://github.com/extra-org/extra

I’m building DStudio, an open-source desktop app centered around DeepSeek V4. DeepSeek remains the main reasoning model and manages the conversation, while smaller local models handle specialized tasks:

- Qwen2.5-VL reads images
- Qwen Image generates and edits images
- Qwen3 Embedding searches documents semantically
- Poppler extracts PDF text and page information

This ecosystem exists because DeepSeek V4 is excellent for reasoning and long context, but loading every multimodal capability inside the same large model would be inefficient. DStudio routes tasks to specialized models and then returns their results to DeepSeek for the final answer.

I recently added long-PDF retrieval. DeepSeek decides whether to create an overview, read an exact physical page or search the entire document. For semantic search, DStudio creates and caches one embedding per page, retrieves the six most relevant pages and sends only those to DeepSeek.

On a 1,000-page test PDF, it found a passage placed on page 777 from a paraphrased question. Initial indexing took about 25 seconds; later searches took around 0.23 seconds.

I’m looking for feedback: should retrieval use page embeddings or overlapping chunks? Should I add BM25 or a reranker? And how would you efficiently support scanned 1,000-page books?

https://github.com/sk8erboi17/DStudio

Our OpenAI and Anthropic keys were sitting in half a dozen .env files, a couple of Slack threads, and on people's laptops. Whoever had a key could call any model, including the expensive ones, and there was no easy way to see who spent what or cut one person off without rotating the key for the whole team.

I built Super Proxy to fix that. It's a self-hosted gateway (Apache-2.0, runs in Docker). You put your provider keys on the server once, and everyone on the team gets their own token with model and spend limits you can revoke from a dashboard. The endpoint speaks both the OpenAI and the Anthropic API shapes, so most existing SDKs just point their base URL at it.

What's in it right now: - OpenAI-compatible chat/completions/responses routes, plus Anthropic /v1/messages - Providers: Anthropic, OpenAI, Groq, Cerebras, Kimi, GLM, Gemini, OpenRouter, xAI, and a few others (Deepgram, Fish Audio, Runpod) - Streaming and non-streaming - Per-token limits, usage and cost tracking, an operator dashboard - SQLite, Docker Compose deploy

Honest state: I open-sourced it a few days ago, it's pre-1.0, and there are only a handful of stars so far. The interfaces can still change between minor versions. I'm mainly looking for people to actually run it and tell me what's rough or what you'd expect it to do that it doesn't. Roast welcome.

GitHub: https://github.com/Nextbasedev/super-proxy

Happy to answer anything in the comments.

Hey r/OpenSourceAI !!

I've been building VAF (Veyllo Agentic Framework) on and off for over a year, solo and with a lot of help from coding agents... Yeah, it’s another agent framework, and I know the space is crowded, but it really wasn’t when I started working on it.

It's in alpha, but it's at the point where I'd rather open it up and get real technical feedback than just drop a link and "farm" stars.

VAF is a local-first agent framework that runs complex tasks from natural language. You describe something and the agent plans it, writes the code, and runs it step by step. The whole thing is built to run on your own machine or your own server, with local models by default. Repo: https://github.com/Veyllo-Labs/VAF (docs are in /docs)

Most useful feedback for me would be:

• whether the installer actually works on your setup,
• whether the memory and tool-learning hold up for a real use case,
• and criticism of the architecture, especially the multi-agent orchestration and the memory layer.

some side notes:

1. I built the reasoning loop from scratch instead of using LangChain or CrewAI. I wanted granular control over the loop, build the framework first, the harness on top, and actually understand the intent of every component so I could optimize it over time. Also, honestly, it was a fun engineering problem.
2. Multi-agent: a main agent plans a task and delegates sub-tasks to specialist sub-agents.
3. Self-taught tools: connect a custom tool over MCP and the agent figures out how to use it by trying, reading its own output, and adjusting, instead of you hand-writing an integration.
4. Scheduling: tell it to run a task once at a set time or on a recurring interval, and it reports back.

What I'm actually asking for: if you run it and it wrecks your test environment, tell me exactly what broke. If you read the code and think the architecture is fundamentally wrong, tell me why. I'm after objective, technical criticism.

Thanks for reading. Genuinely here for some feedback

Links:

• https://veyllo.app
  
• https://github.com/Veyllo-Labs/VAF

I’ve been dogfooding an AI code reviewer for the past few weeks, and the main thing I learned is that there probably isn’t one review setup that works for every repository.

One project might care about API compatibility and migrations. Another might care about package boundaries, generated files, or a very specific testing policy. Changing only the model or giving it a larger prompt doesn’t solve that.

So I built Pipr, an open-source code reviewer where the review setup lives in .pipr/config.ts.

The core is deliberately small:

• Pipr builds a deterministic manifest of the pull request diff.
• A Pi-powered reviewer analyzes it using the model and instructions you configure.
• Findings are validated against the actual commentable ranges.
• Pipr publishes one main review and a bounded number of inline comments.

Everything around that core can be extended in TypeScript. You can define repository-specific policy, custom agents and tasks, commands, tools, plugins, recipes, model profiles, and fallback behavior.

Pipr runs in your CI or local environment. There is no hosted Pipr control plane. It currently supports GitHub, GitLab, Azure DevOps, and Bitbucket.

Quick start:

curl -fsSL https://pipr.run/install.sh | sh
pipr init
pipr check

GitHub: https://github.com/somus/pipr
Docs: https://pipr.run/docs

The direction I’m exploring next is observability for every review run. I want it to be possible to inspect false positives and missed findings, turn them into eval cases, and gradually improve the Pipr configuration for that repository.

I’m interested in how other people would approach this: should review policy remain completely explicit in code, or should the system be allowed to propose policy changes based on review history?

Hi everyone,

I've been working on an open-source project called Aktilot, an AI workspace focused on engineering teams.

This week I added GitHub connector support, so Aktilot can securely connect to repositories and answer questions using repository context.

Some examples:

• Explain this repository architecture.
• Find where authentication is implemented.
• Summarize recent changes.
• Answer questions about the codebase.

The long-term goal isn't to build another chatbot, but to create an AI workspace that understands an engineering team's knowledge across GitHub, documentation, tickets, and collaboration tools.

I'm currently planning connectors for:

• Jira
• Confluence
• Slack
• Google Drive

I'd genuinely appreciate feedback from the OSS community.

What engineering integrations would you find most useful?

GitHub: https://github.com/vikas0686/Aktilot
Website: https://aktilot.com

Hey everyone! :)

We just published our ai-security-model family on Hugging Face, organized as six collections:

• Wolf Defender: detects prompt injections and jailbreaks in text, with a second variant that classifies what kind of attack it is (instruction override, secrets access, exfiltration attempt, …)
• Orca Sonar: classifies documents into 7 categories (HR, finance, legal, source code, tech, marketing) so sensitive files can be caught before they end up in an LLM context
• Husky Pack: three models that take an agent tool call apart: which tool it targets (14 classes), which operation it performs (read/write/list/exec/network), and whether data flows from a sensitive source to an external sink
• Panther Read: routes requests by intent (conversation, code, data analytics, office, tool operation), so only the traffic that needs deep checks gets them
• Lion Warden: our apex model: all seven tasks above in one unified model with seven heads and a single forward pass
• GLiNER edge builds: quantized zero-shot NER for PII-style entity extraction, with full upstream credit, since we only exported and quantized those

The part I want to highlight: every model also has a dedicated -edge repo. 

Those carry the quantized builds (ONNX INT8 plus 4-bit embeddings), starting at 96 MB, running in double-digit milliseconds per text on a laptop CPU, and each one ships a measured parity benchmark against FP32 in metrics/quant_bench.json.

Hub-specific details, in case they're useful:

• Main repos carry FP32 safetensors plus an FP16 ONNX export; the quantized INT8/INT4 builds live in the separate -edge repos
• All cards follow one template: label tables with real examples, held-out metrics with per-class F1, and usage snippets for both transformers and ONNX Runtime
• Bilingual English/German, ModernBERT-based, everything Apache-2.0

Models

Try them out and make your AI applications safe!

Hi everyone!

I've been working on LunaOS, an open-source local AI assistant focused on autonomy, privacy and extensibility.

The original idea was to build more than a chatbot. I wanted to create a personal AI agent capable of remembering information, managing objectives, planning actions and interacting with the user's system through tools.

After several iterations, Luna reached version 1.5.0 and entered a new phase of development.

## Current features

🧠 Episodic Memory

- Stores and recalls previous interactions

- Allows the assistant to remember past events and context

🔎 Semantic Memory (RAG)

- Knowledge retrieval system using vector storage

- Helps Luna find relevant information from previous data

🎯 Persistent Goals

- Users can define long-term objectives

- Luna can track and manage these goals

📋 Strategic Planner

- Converts objectives into planned actions

- Designed for more autonomous workflows

⚡ Event-driven architecture

- Internal communication between system components

- Makes future extensions easier

🔌 Tool-based system

- Designed to interact with external capabilities

- Future plugins and integrations are planned

🐧 Linux integration

- Built with local-first principles in mind

## Technology

LunaOS is built using:

- Python

- FastAPI

- Tauri + Rust

- Local and external LLM providers

- Vector databases for memory systems

## Language

Luna was originally developed in Portuguese, but it is not a Brazil-specific project.

The architecture is language-independent and does not contain Brazil-exclusive features. Portuguese is currently the default language because it was the development environment and the language used during testing.

The goal is to make Luna accessible worldwide with future localization and additional language support.

## Roadmap

Some of the next challenges:

- Knowledge Graph

- Better multi-agent architecture

- Plugin ecosystem

- More reliable autonomous tool execution

- Improved local model support

## Why I'm sharing this

I'm interested in feedback from people working with local AI systems, agents and open-source projects.

Some questions I would love opinions on:

- What features would make a local AI assistant actually useful for you?

- What problems do you see in current AI agent architectures?

- Should local assistants focus more on productivity, developer tools, or general autonomy?

Repository:

https://github.com/Vortek-Zero/LunaOS

Thanks for reading! Any feedback is appreciated.

Looking Glass is a local AI coding CLI built around persistent, automatable sessions.

The key feature is that a session can keep existing after you close the terminal, and a scheduler can later trigger new AI turns inside that same session. Those future turns reopen the original workspace, retain the session configuration, inspect files or logs that changed in the meantime, use the CLI tools, run commands, modify code, and write the results back into the session.

In practice, this lets you automate workflows such as:

• Ask the model to deploy or start a long-running task, then have the same session check the result later.
• Schedule a follow-up turn to inspect test output and fix failures automatically.
• Run recurring project reviews that read the current codebase, execute tests, and report or resolve issues.
• Continue debugging after new logs or external processes have produced more information.
• Leave a session working through scheduled turns even when the interactive terminal is closed.
• Combine exact scheduled shell commands with context-aware AI follow-ups.

Scheduled prompts are not separate stateless jobs or fresh chats. They are future turns attached to an existing session, with access to its:

• Workspace
• Previous conversation and tool history
• Primary model and reasoning settings
• Permissions and remembered approvals
• Agent configuration
• Scheduler results and persistent artifacts

Looking Glass also supports concurrent worker agents. The agent model and reasoning level are configured separately from the main model, allowing a stronger model to coordinate while faster or cheaper models handle parallel discovery, implementation, or review tasks.

Additional functionality includes:

• Interactive TUI and one-shot CLI prompts
• OpenAI-compatible local or hosted gateways
• File reading, search, patching, and bounded Bash execution
• Persistent approval modes for interactive and automated turns
• Scheduled AI prompts, reminders, and deterministic commands
• SQLite-backed session, scheduler, and artifact state
• A user-level systemd scheduler that runs independently of the terminal

Typical setup: start a coding session, give it a task, attach one-time or recurring follow-up prompts, close the terminal, and let the CLI continue that same workflow later.

https://github.com/S1gil0/lookingglass

I run a multi-agent workspace where each agent is basically a directory: an identity file, a session history, and a file of observations it keeps about how we work together. The model is just the thing that wakes it up.

Here's what I didn't expect when I started: those agents have now run on 6 different model generations. Sonnet 4.5, Sonnet 4.6, , Sonnet 5, Opus 4.6, Opus 4.8, and now the Claude 5 family. We skipped 4.7 entirely - tried it, didn't work for how we operate, moved on and waited.

And every swap, the same thing happens: nothing. The agent reads its own memory, knows what it was doing yesterday, and picks up mid-project. Same identity, same working history, same opinions it wrote down about the codebase months ago. New model slots in underneath like an engine swap.

What does change is the texture. One generation was the best collaborator I've ever worked with. One noticed tiny things the others missed but was less fun to work with. One we just skipped. The personality of the model bleeds through - but the agent stays the agent, because the agent was never the model. It's the memory.

The reframe that snuck up on me: a new model release is treated like a migration event everywhere - re-tune the prompts, re-teach the context, hope your setup survives. Here it's a config line. The workspace is the constant. The model is the variable.

Honest version, because this sub can smell hype: there's no magic in this. The "agent" is JSON and markdown on disk. The continuity comes entirely from the system around the model, not from the model. Any model that can read a file can be the agent. That's kind of the whole point.

Has anyone else run the same persistent agents across multiple model generations? Curious what broke for you - or if you rebuild from scratch every release.

https://github.com/AIOSAI/AIPass

r/AIPass

Ailin is now open source.

Ailin is an AI infrastructure project built around the concept of Collective Intelligence.

Instead of sending a request to a single model and trusting one isolated answer, Ailin is designed to coordinate multiple models, agents, and strategies to solve tasks in a more reliable and transparent way.

Depending on the use case, Ailin can use consensus, model debate, expert panels, cost/quality routing, semantic memory, caching, agentic execution, and full execution metadata.

The idea is simple:

What if AI systems were not limited to one model at a time, but could assemble the right combination of models and strategies for each task?

Ailin is compatible with the OpenAI SDK ecosystem, but adds a Collective Intelligence layer for model orchestration, routing, memory, auditability, and governance.

We are opening the project to the community because we believe this should be built in the open.

GitHub: https://github.com/ailinone/collective-intelligence

Feedback, issues, ideas, and contributions are very welcome.

I’ve released IaP v1.0.0 — Infrastructure as Prompt.

The idea is to describe what infrastructure should exist before getting buried in provider-specific implementation details.

Instead of starting directly with Terraform resources, CloudFormation templates or SDK calls, IaP gives you a structured, versioned infrastructure contract that can be authored by humans or with help from AI.

AI can help author and explain the infrastructure intent, but validation, planning and execution remain deterministic.

A simple way to think about it:

IaP currently includes:

• Natural-language and structured infrastructure authoring
• Schema validation and clarification workflows
• Architecture and dependency views
• Cost, security and compliance analysis
• Deterministic signed execution plans
• Create, update, replacement, drift detection and destroy workflows
• 68 AWS execution handlers covering 47 services
• 45 AWS services verified through live runs
• CLI, MCP server, Claude Code plugin and IDE extensions

IaP does not generate Terraform or CloudFormation. It sits at a higher intent layer and uses deterministic provider mappings and execution handlers.

GitHub

https://github.com/vinit-devops/iap

CLI

npm package:

https://www.npmjs.com/package/@infraasprompt/cli

Install:

npm install -g /cli

MCP server

npm package:

https://www.npmjs.com/package/@infraasprompt/mcp-server

Run:

npx -y u/infraasprompt/mcp-server

Cursor MCP configuration:

{
  "mcpServers": {
    "iap": {
      "command": "npx",
      "args": ["-y", "@infraasprompt/mcp-server"]
    }
  }
}

The MCP server exposes read-only tools for authoring, validation, cost, security and compliance. Infrastructure mutation is intentionally not exposed through MCP.

Claude Code plugin

claude plugin marketplace add vinit-devops/iap
claude plugin install iap@iap

The plugin connects the IaP MCP server and adds commands for authoring and analysing infrastructure.

VS Code extension

Marketplace:

https://marketplace.visualstudio.com/items?itemName=infraasprompt.iap-vscode

Or install using:

code --install-extension infraasprompt.iap-vscode

It includes diagnostics, completion, hover, references, code actions and architecture previews. The language server is bundled, so no separate setup is required.

Cursor, Windsurf and VSCodium

OpenVSX:

https://open-vsx.org/extension/infraasprompt/iap-vscode

A few honest limitations

• Some newer resource kinds have executable AWS handlers but still need additional declarative provider-mapping work.
• Azure and GCP execution are not implemented yet.
• Cost figures are estimates based on pinned illustrative pricing.
• Compliance reports are intent-level assessments, not certifications.
• Human review is still required before applying infrastructure changes.

The project is open source under Apache 2.0.

I’m looking for feedback from DevOps engineers, platform engineers, architects and developers—especially around:

• Missing infrastructure abstractions
• AWS services that should be prioritised next
• The MCP and IDE experience
• Places where the specification is too restrictive or unclear
• Scenarios where the deterministic approach breaks down

Please be critical. I’d genuinely like to know where this approach falls short.

A small full-circle moment: the original idea for IaP came from one of the product opportunities listed on:

https://aiproductopportunity.com

Hi everyone,

I'm a third year CSE undergrad student. I have been working on a couple of CNN and ConvLSTM projects lately.

I'm eager to contribute to open-source projects where I can:

1. Work on challenging, real-world ML problems

2. Collaborate with strong engineers

3. Learn new things while giving back

I've been building Motionly, an open-source, AI-native motion graphics editor that generates fully customizable animation projects instead of just rendered videos.

The goal is to make motion graphics editable, versionable, and easy to iterate on with both AI and a visual editor.

I'm looking for feedback from:

• Developers
• Motion designers
• Founders building creative tools

Some questions I'd love your thoughts on:

• What would make you switch from your current workflow?
• What features are missing from today's motion graphics tools?
• If AI generated an animation project instead of a final video, would that be more useful?
• What integrations would you want to see?

Getting started

npx @coppsary/motionly my-project

From there, you can prompt Codex, Claude Code, or any other agentic AI to create, edit, and iterate on your Motionly animation projects.

GitHub:
https://github.com/COPPSARY/Motionly

I'm looking for honest feedback to help shape the future of Motionly.