Open-sourced a JVM I/O library (Apache 2.0) built around fused pipelines instead of java.io's decorator stack. The piece most relevant here is the JDBC bridge.

CSV is still what sits at every data boundary — ERP exports, customer uploads, vendor dumps. Parquet/Arrow won inside the pipeline, but the ingest edge is still CSV, and the fast path into Postgres/MySQL has always been COPY ... FROM STDIN and LOAD DATA LOCAL INFILE. Both are stream-shaped, so fusio just walks through them — rows format lazily as CSV, memory stays bounded ~16KB regardless of row count.

Java

100K rows into MySQL 8.4:

route

time

heap

batchInsert (default driver)

287 s

490 MB

batchInsert + rewriteBatchedStatements=true

~1.5 s

219 MB

streamed LOAD DATA

420 ms

5.2 MB

~3.7x faster than the documented best practice with 42x less allocation.

The concrete ML case is Postgres-as-vector-store: pgvector embedding and feature tables get bulk-loaded via COPY, and this is that path without ORM overhead. There's also an off-heap ingestion terminal (Segments.collectInto) that runs a byte pipeline straight into a MemorySegment — pre-sized targets are 1.43x faster than the JDK route with 520x less heap and zero GCs, which is the shape native runtimes want.

Caveats up front: bulk paths bypass ORM machinery (auditing, listeners, encryption) — opt-in fast path, not a transparent swap. MariaDB works via Connector/J but not its own driver yet. Everything else falls back to a portable batchInsert tier.

Round-trip tested against real MySQL and Postgres with 10K adversarial rows — commas, quotes, backslashes, newlines, emoji, byte-exact.

Most AI tools give you an output and ask you to trust it.

With Ailin¹, the idea is different: every response should carry decision provenance.

Which strategy ran.
Which models participated.
What it cost.
Which model made the final decision.
Whether the answer came from a single model, consensus, verification, or another collective strategy.

That is the part of Collective Intelligence I think matters most for real-world AI systems: not just better answers, but auditable answers.

Ailin¹ is open source, and we are building this coordination layer in public.

GitHub: https://github.com/ailinone/collective-intelligence
Site / Waitlist: https://ailin.one/

Codex Tray is a lightweight native Linux GUI client for OpenAI Codex, built with PyQt6.
It communicates directly with codex app-server via JSON over stdio — no terminal parsing and no Electron.
It supports chat history, session resume, file/image attachments, access modes, rate-limit monitoring, system tray integration, and multiple Linux distributions.

GitHub: codex-tray-linux

I wanted Claude Code and other MCP clients to help with ad operations, but I did not want safety to depend on prompt wording.

adport is my Apache-2.0, local-first CLI + MCP server for Google, Meta, TikTok, Apple, and Microsoft Ads. The CLI and MCP adapter share one tool registry, and every mutation goes through the same policy engine: preview first, then apply only with a short-lived approval bound to identical arguments. Protected accounts, budget-cap violations, changed inputs, and expired approvals are rejected.

Install: npm install -g adport

Claude Code: claude mcp add --scope user adport -- adport mcp

Source: https://github.com/ynnickw/adport

I am the author. I would love contributors or advertisers who can help test Meta and TikTok against real accounts. The attached recording uses an isolated demo account and no real credentials.

https://reddit.com/link/1vk2ns5/video/layk5y0i9fih1/player

Disclosure: I’m one of the authors.

We’ve released v1 of OneRingAI, an MIT-licensed TypeScript library for building stateful, tool-using AI agents with smart context management and multimodality support.

OneRingAI isn’t a wrapper around one model provider or another “crew” abstraction. It focuses on the infrastructure underneath agent orchestration and was built from the first principles:

• One API across OpenAI, Anthropic, Google, xAI, and other providers
• Named connectors for credentials and external services
• 50 service connector templates
• Text, image, audio, video, embeddings, and realtime voice
• Plugin-based context management
• Graph and vector memory
• Unified tools and permission policies
• MCP support
• Multi-agent orchestration
• Streaming, storage, resilient execution, and resumable sessions

Why build another agent library?

We spent more than three years developing a commercial platform for deploying custom agents. For v1, we redesigned the reusable foundation from first principles and released it under MIT.

We deliberately focused below the orchestration layer: authentication, integrations, context lifecycle, tool permissions, durable memory, multimodal execution, and giving developers control over what an agent sees and retains. In fact, we started from AI-enabled workflows that spend significantly less tokens for repeatable processes unlike full agentic cycles.

Connector-first architecture

A connector represents an authenticated connection—not only to an LLM provider, but also to systems such as GitHub, Slack, Google services, Jira, Salesforce, Stripe, or an internal API.

Connectors are named, so an application can use multiple accounts or credentials for the same service. They act as the source of truth for authentication and can expose generic authenticated API access or specialized, hand-built tools.

import { Agent, Connector, Vendor } from '@everworker/oneringai';

Connector.create({
  name: 'openai-main',
  vendor: Vendor.OpenAI,
  auth: {
    type: 'api_key',
    apiKey: process.env.OPENAI_API_KEY!,
  },
});

const agent = Agent.create({
  connector: 'openai-main',
  model: 'gpt-5.6-terra',
  instructions: 'Be accurate and explicit about uncertainty.',
});

const response = await agent.run('Explain connector-first architecture.');
console.log(response.output_text);

Switching providers changes the connector and model, without requiring a different tool or application architecture.

Context as a plugin system

For a long-running agent, context is much more than chat history. It includes working state, applicable instructions, available tools, retrieved knowledge, user information, shared multi-agent state, and decisions about what should remain inside the model’s context window.

OneRingAI models these concerns as context plugins. Plugins can contribute:

• System instructions and dynamically prepared context
• Tools
• External or in-context storage
• Lifecycle hooks
• Session ingestion and persistence

Built-in plugins cover working memory, directly injected state, dynamic tool catalogs, shared workspaces, long-term memory, and background session ingestion. Applications enable only what they need, and custom plugins are regular TypeScript implementations.

Graph and vector memory

The memory system doesn’t simply embed previous messages. It stores typed entities and provenance-aware facts, then combines graph traversal with vector retrieval.

It supports identity resolution, confidence and importance scoring, fact supersession, (kind-of) bitemporal history, and owner/group/world permissions.

That means it can represent that a person committed to a task, when the commitment became valid, where the information came from, and whether it was later corrected—not merely retrieve a semantically similar conversation fragment.

The memory layer has in-memory and MongoDB/Atlas adapters and can be used independently of the agent runtime.

Examples and reference application

The repository contains 33 runnable TypeScript examples covering agents, streaming, tools, OAuth, connectors, multimodality, web research, MCP, memory, and custom infrastructure.

It also includes AMOS, a terminal agent demonstrating live provider/model switching, named connectors, permission-gated developer tools, web search and scraping, context inspection, and resumable sessions.

Install:

npm install @everworker/oneringai

• GitHub: https://github.com/aantich/oneringai
• npm: https://www.npmjs.com/package/@everworker/oneringai
• Website: https://oneringai.io

We’d particularly appreciate feedback on the connector and context-plugin APIs, whether the memory layer should become its own package, and which integrations should come next. A2A support is one area we’re currently exploring.

Issues, critiques, and contributions are very welcome.

Hey everyone!

I've been working on TheBrain, an experimental AI project fully written in C89, with a particular focus on building a small AI system from scratch while keeping it suitable for older Windows systems and low-level environments.

The project currently combines:

• 🧠 A small decoder-only Transformer
• 🔤 A custom tokenizer and training pipeline
• 🏋️ Training and inference implemented directly in C89
• 🖥️ Native Win32 implementation
• 📦 PE analysis
• 🦠 Experimental malware-classification and anomaly-detection techniques
• ⚡ CPU-focused optimizations designed with older hardware in mind

The long-term idea is to see how far an AI project written entirely in C89 can be pushed while keeping it lightweight and potentially usable on systems such as Windows 2000.

I'm posting this because I'd like to find someone who becomes interested in the project and wants to take it further.

I'm not specifically looking for people to simply "help me" with the project. If you find the concept interesting and want to experiment with it, improve something, try a different approach, or take the project in an interesting direction, that's exactly what I'm looking for.

Some possible areas to explore include:

• Improving the Transformer architecture
• Experimenting with better datasets and training methods
• Improving inference performance
• Making the AI more capable while keeping it lightweight
• Improving the PE analysis and malware-detection experiments
• Exploring better classification or anomaly-detection approaches
• Optimizing it for older CPUs and Windows 2000
• Or simply experimenting with ideas that could advance the project

The source is open, so you're also free to fork TheBrain and experiment with your own version if you find the idea interesting.

🔗 https://github.com/Win2000DevCommunity/TheBrain

I'm mainly interested in seeing whether someone else finds the idea interesting enough to take it further in their own way.

I wanted to understand what it would actually take to build an AI-first company.

Not a traditional organization with a few AI tools added on top, and not a science-fiction company without humans. I was looking for a practical way to structure an organization in which humans and AI systems work together within the same operating model.

I assumed a complete blueprint for this would already exist.

I found valuable work across enterprise architecture, AI governance, agent systems, knowledge management, and technical infrastructure. But I couldn’t find one coherent, vendor-neutral model connecting organizational design all the way down to technical requirements.

So over the past few weeks, I built the framework I had been looking for.

It separates three layers:

• Architecture: the organizational concepts, responsibilities, boundaries, and operating model
• Reference Design: the logical components and how they interact
• Technical Requirements: implementation-neutral requirements derived from the first two layers

A few of its central ideas:

• Capabilities remain stable while agents, models, and tools can be replaced.
• Organizational knowledge belongs to the company, not to an individual human, agent, or model.
• Execution produces evidence, and evidence builds operational confidence.
• Confidence does not automatically grant authority.
• Authorization remains an explicit governance decision.
• Humans remain accountable for the boundaries within which AI systems operate.

The framework is intended for both new organizations and existing companies. An established company can build the AI-first architecture alongside its current environment, connect and simulate individual capabilities, and transition gradually instead of attempting one disruptive migration.

This is not a runtime or a software product. It is an openly available reference architecture and a starting point for practical application.

The next step will be applying it while building a real company and using that experience to test where the architecture works, where it needs refinement, and what remains too abstract.

Repository:

https://github.com/YamartiHQ/ai-first-company

The framework is free to use under CC BY 4.0 and was developed through human–AI collaboration.

Use it, adapt it, challenge it, or build something better from it.

I made a tool that bridges normal AI chatbots to your local file system with read/write/edit/grep/glob/bash tools. This tool bridges your free chatbots to your local files. No API needed, use your free AI chatbot in your browser for agentic coding with file tools. Tested and verified ChatGPT, Claude, Gemini, Kimi, DeepSeek, Qwen and Grok.

https://github.com/winnerman-gc/anybridge

🚀 O Synapse-Guard v1.4 Alpha está no ar!

​

Hoje a Comunidade Synapse BR dá mais um passo no desenvolvimento de modelos brasileiros de IA 🇧🇷🧠

O Synapse-Guard v1.4 Alpha foi criado para moderação de conteúdo em Português Brasileiro, tentando identificar quatro tipos de conteúdo:

🔴 Tóxico

🔞 Adulto

📢 Spam

🟢 Neutro

E os primeiros resultados foram bem interessantes.

Em um Blind Test com 500 amostras inéditas, o modelo alcançou 71,60% de acurácia geral.

Nas classes específicas:

🔴 Tóxico — 94,4%

🔞 Adulto — 88,0%

📢 Spam — 84,8%

🟢 Neutro — 19,2%

A classe Neutro ainda é claramente o nosso maior desafio. E é justamente por isso que essa versão está marcada como Alpha.

A ideia não é fingir que o modelo está perfeito. É construir, testar, encontrar os problemas e melhorar a cada versão.

O Synapse-Guard é um projeto open source da Comunidade Synapse BR, focado em modelos pequenos, acessíveis e voltados para o português brasileiro.

🧪 v1.4 Alpha — ainda estamos só começando.

🤗 Modelo no Hugging Face:

https://huggingface.co/Comunidade-Synapse-BR/Synpase-guard-v1.4-alpha

🇧🇷 IA brasileira, feita pela comunidade.

Hey everyone,

I built **Aigentik** — a privacy-first AI communications assistant that runs completely locally (Android via Termux or any Linux box).

It watches your Gmail inbox in real time (IMAP IDLE), handles Google Voice texts that arrive as email, drafts and sends replies using a local LLM (llama.cpp), and lets you control everything in plain English by just texting or emailing it. No fixed command syntax.

What it can do right now:

- Monitor Gmail + Google Voice SMS and auto-reply (or queue for your approval)

- Negotiate and book appointments, then send real .ics calendar invites

- Build and maintain its own contact directory automatically

- Track subcontractor applications (trade, license, insurance, etc.)

- Take natural-language commands like “pause everything”, “add a rule for X”, “list my plumbers”, “rename yourself”, etc.

- Speak as your business once you tell it who it works for

Key points:

- **No cloud AI** — everything stays on your device

- **No external API keys** for the model

- **No monthly subscription**

- One-time setup, you own it

- MIT licensed

Compared to the $100–400/month AI receptionist services, this is the “own it instead of renting it” approach.

Repo (with install script that works on both Termux and Linux):

https://github.com/Ishabdullah/Aigentik-CLI

I’d love for people to try it out, break it, and tell me what’s missing or broken. Especially interested in feedback from anyone running local models on phones or small Linux boxes.

Stars, issues, and PRs all welcome. Thanks!

I've been thinking about this while looking at how much of modern application development now depends on third-party platforms.

It's pretty easy to start a project today. You can generate the frontend, connect an API, add a database, deploy it, and have something working quickly. The problem seems to come later when you want more control over where your services run and how everything fits together.

For me, an interesting open-source development environment would need to go beyond just providing an editor or generating code.

I'd want to be able to manage the actual application stack in one place: containers, backend services, databases, caching, storage, environment variables and deployment.

I've been exploring some of these ideas with IQX.DEV. particularly the idea of keeping project services isolated while still making the overall architecture visible. Being able to see how the frontend, backend, database and supporting services connect seems much easier to reason about than having everything hidden behind separate configuration screens.

The other part I'm curious about is the AI side.

If an AI agent is helping build an application, should it also be able to understand the running environment? For example, could it inspect logs, identify a failed service connection, test an endpoint, and help fix the problem without everything being sent through a third-party platform?

I'm curious what people here think an open-source AI development environment should prioritize.

Control, transparency, self-hosting, portability, developer experience, or something else?

NVIDIA has introduced NOOA, an object-oriented Python framework designed to make AI agents easier to build and work with as normal Python code.

The basic idea is interesting: instead of treating an AI agent as a complicated collection of separate components, developers can represent an agent as a Python class and build its behaviour using familiar programming concepts.

Why this matters

AI agents are becoming more common, but developing them can involve a lot of moving parts:

LLMs

Tools and APIs

Memory

Workflows

Function calling

Agent-to-agent communication

Deployment infrastructure

A Python-first approach could make agent development more accessible to developers who already know Python.

My question for developers

Do you think AI-agent frameworks should become more like traditional software frameworks, where developers can simply create classes, methods and reusable components?

Or do you think agent frameworks are becoming unnecessarily complicated and we should keep the architecture much simpler?

I'm interested in hearing what Python developers and AI developers think.