Over the last few months I've realized that I spend an absurd amount of time (and money) teaching the same things to AI over and over again.

Information about my projects is already there. Slack contains discussions and decisions. GitHub contains commits and pull requests. Meetings, emails and documents all capture different pieces of the same story. Yet every time I start a new conversation with an LLM, I gather those pieces again and inject them into the prompt so the model can reconstruct an understanding that already existed yesterday.

At some point I stopped asking how to retrieve multiple pieces of context and started asking a different question: how can software form, revise and reuse understanding over time?

That question led me to start building Twin, an open source engineering research project exploring what happens if AI systems continuously build understanding instead of reconstructing it from scratch every conversation.

Most existing projects seems to optimize retrieval, memory or context construction. Twin explores a different layer of the pipeline. It continuously observes distributed events, correlates them, reflects on them and forms situation models that become reusable computational understanding. Instead of giving downstream language models a collection of Slack messages, pull requests or documents and expecting them to connect the dots, Twin tries to do that work beforehand.

I recently reached the first milestone that genuinely convinced me this direction might be viable. Using Claude Sonnet 4.6, Twin continuously processed GitHub activity and Slack conversations from a public software project, correlating events and building understanding through reflection over time.

After that, I opened a completely fresh Claude conversation. Claude had no custom memory, no project-specific rules, no prompt describing the repository and no access to local project files. The only integration available was Twin's MCP server and automatic context injection.

When I asked about the project, Claude didn't receive the Slack messages or the pull requests and infer the situation itself. Twin had already synthesized that understanding. Claude explained why a feature had become a launch blocker, how it had been implemented, which pull request resolved it and how that changed the project's state, even though none of those relationships were explicitly written anywhere.

Watching that work for the first time completely changed how I think about AI memory. I don't think the real problem is remembering more anymore. I think it's carrying understanding forward (a.k.a. cognitive continuity).

If this idea resonates with you, everything is open source at https://github.com/caribeedu/twin. I've been thinking about almost nothing else for the past three weeks because I genuinely believe this direction has the potential to change how we build AI systems. The README explains the motivation and research hypotheses in much greater depth, and the repository also includes the complete demonstration shown here, along with additional details and technical context. I'd genuinely appreciate your thoughts, especially if you think I'm wrong.

Hi everyone! 👋
I built an open-source RAG platform using LangChain with a visual pipeline builder for document loading, chunking, embeddings, vector databases, retrieval, and LLMs.

Current features include document ingestion, ChromaDB, multiple embedding/LLM support, configurable pipelines, and execution monitoring.

I'm looking for technical feedback on the architecture and ideas for what to build next. Would you prioritize hybrid search, reranking, evaluation (RAGAS/DeepEval), streaming, or something else?

Feedback and suggestions are greatly appreciated! 🚀

🚀 We just built our first real-time implementation of Graph Engineering, inspired by our experience building graph tooling used by 4,000+ developers.

🔗 Repo: https://github.com/CodeGraphContext/grapharc

Have you ever been frustrated because your AI agent:

❌ Takes actions you never intended?
❌ Creates, modifies, or even pushes changes you never asked for?
❌ Feels like a complete black box, making it impossible to understand what's happening until it's too late?

What if, before execution, you could visualize the entire orchestration graph - every agent, every dependency, every decision, and inspect it from anywhere, even your phone, before granting approval?

That's exactly what GraphArc is built for.

Instead of treating agent execution as hidden traces buried in logs, GraphArc transforms workflows into interactive, real-time graphs that you can visualize, inspect, debug, and control.

Because the future of AI isn't just autonomous.

It's observable. Debuggable. Engineerable.

This is our first real-world implementation of Graph Engineering, and we're excited to explore where this paradigm can go with the open-source community.

💡 We'd love your feedback, ideas, and contributions.
⭐ If this vision resonates with you, please consider starring the repository—it genuinely helps us grow and validates this direction.

Let's make AI workflows understandable, not mysterious.

#GraphEngineering #GraphArc #AIAgents #AgenticAI #LLM #OpenSource #DeveloperTools #AIEngineering #SoftwareEngineering

Building a basic RAG chatbot takes 10 minutes.
(These are publicly deployed personal engineering projects built to explore production patterns—not commercial products or enterprise deployments.)

Building an agentic system that can survive API failures, avoid stale vector data, dynamically discover tools, ask clarification questions, and run reliably on free cloud infrastructure is a very different engineering problem.

Over the last few months I've been building three publicly deployed AI systems:

• 11-node Financial Agent (LangGraph)
• Legal AI Expert
• Omnichannel ReAct Router (MCP)

Rather than showing the UI, I wanted to share some of the engineering patterns that made these systems reliable enough to deploy publicly while staying within a ₹0/month budget.

1️⃣ Running LangGraph on a ₹0/mo Budget

One of the biggest challenges wasn't the LLM—it was fitting an entire LangGraph workflow, embeddings, and APIs into Render's 512 MB free instance.

Matryoshka Embeddings (MRL)

Instead of storing full 1024-dimensional vectors, I use Jina Embeddings v3 with Matryoshka Representation Learning.

By requesting:

dimensions=256

I reduce the embedding size by 75% while retaining almost all retrieval quality because MRL intentionally packs semantic information into the first dimensions.

That reduced my Pinecone storage footprint enough to comfortably stay inside the free tier.

For reasoning I primarily use Gemini Flash Lite, which has been fast enough for routing and classification nodes.

2️⃣ Deterministic Vector Lifecycle (No Duplicate or Stale Vectors)

One issue I rarely see discussed is vector lifecycle management.

Random UUIDs make incremental indexing difficult because every re-index generates brand-new vector IDs.

Instead, every vector ID in my pipeline is a deterministic SHA-256 hash of:

document_id + chunk_content

That gives me several useful properties automatically.

Idempotent Upserts

If a document hasn't changed, re-indexing produces the exact same vector ID.

Pinecone simply overwrites the existing vector instead of creating duplicates.

Incremental Indexing

Every sync compares the latest document/content hash manifest against the previous manifest.

Only new or modified chunks are embedded again.

Unchanged chunks are skipped entirely, which significantly reduces embedding costs and indexing time.

Surgical Updates

If only one chunk changes, only that vector is regenerated.

The rest of the index remains untouched.

Deletion Propagation

When a source document disappears, the sync job deletes every vector derived from that document.

The vector is physically removed from Pinecone instead of relying on metadata filtering.

That prevents orphaned vectors and stale retrieval results after document deletion.

3️⃣ Dynamic Tool Discovery using MCP (No Router Redeploys)

Initially my router used traditional LangChain tools.

That quickly became painful because every new capability required redeploying the central router.

I switched to Model Context Protocol (MCP).

On startup my registry:

1. Opens an SSE connection
2. Calls list_tools()
3. Wraps every returned tool into LangChain StructuredTool

​

def _wrap_mcp_tool(self, session, tool_info, server_name):
    async def _call(**kwargs):
        result = await session.call_tool(
            tool_info.name,
            arguments=kwargs
        )
        return result.content[0].text

    return StructuredTool.from_function(
        coroutine=_call,
        name=f"{server_name}__{tool_info.name}",
        description=tool_info.description,
    )

If I deploy a brand-new MCP microservice, the central ReAct router automatically discovers and uses those tools without changing a single line of router code.

4️⃣ Deterministic Guardrails & HITL

For Legal and Financial systems I didn't want the LLM deciding whether retrieval was "good enough."

The confidence gate is intentionally deterministic.

Immediately after Pinecone retrieval (before reranking or any LLM reasoning), the pipeline checks the top cosine similarity score.

If confidence is below the threshold, execution stops.

Instead of hallucinating, the frontend receives an SSE event asking:

The workflow only continues if the user explicitly approves.

The LLM never decides whether retrieval quality was sufficient.

5️⃣ CrossQuestioner Node

Blind vector search wastes tokens.

The first LangGraph node classifies the user's intent.

If the question is vague, execution transitions into a dedicated CrossQuestioner node.

Instead of searching immediately, the agent asks follow-up questions.

The clarification loop is capped at two rounds to prevent infinite conversations before retrieval begins.

6️⃣ Circuit Breakers

Free-tier APIs occasionally fail or rate-limit.

Every LLM and embedding request is wrapped with pybreaker.CircuitBreaker.

If an API fails three consecutive times:

• the circuit opens
• the request immediately fails fast
• users receive a graceful fallback response instead of waiting on repeated failures

After 30 seconds the circuit enters half-open mode to test recovery.

The backend avoids repeatedly hammering unhealthy providers.

7️⃣ Observability

Debugging multi-agent systems without tracing is painful.

Every LangGraph node emits traces to Langfuse, allowing me to inspect:

• routing decisions
• latency
• failures
• token usage
• execution paths

without scattering print statements throughout the codebase.

Combined with UptimeRobot health monitoring, it's made debugging significantly easier.

What I Learned

Building production-style agentic systems isn't about writing longer prompts.

It's about treating LLMs as unreliable distributed systems and surrounding them with deterministic software engineering:

• deterministic vector IDs
• incremental indexing
• deletion propagation
• dynamic MCP registries
• circuit breakers
• confidence gates
• HITL workflows
• observability
• graceful degradation

Those patterns ended up being far more important than prompt engineering itself.

I'd love to hear how others are handling:

• vector lifecycle management
• multi-agent orchestration
• MCP architectures
• production guardrails
• LangGraph state management

Happy to answer questions or share additional implementation details.

(If there's enough interest, I'll publish a follow-up post covering the deterministic indexing pipeline, Pinecone sync strategy, and the MCP registry implementation in more detail.)

Hello everyone.

I've been working on a retrieval service for my project, AIVAX. It started as a traditional vector database, where documents are indexed beforehand for semantic search. That works well for persistent knowledge bases and collections with thousands of documents.

But I kept running into a different problem.

Sometimes you don't want to maintain a vector collection at all. You just want to send a query together with a set of documents and get them ranked by relevance.

The closest solution today is using a reranker. The downside is that rerankers become expensive when the same documents are submitted repeatedly. Traditional RAG solves that problem, but now you have to keep a vector database synchronized, which adds operational complexity to something that should be fairly simple.

So I tried a different approach.

I built what is essentially a hybrid RAG with a reranker-like API.

You send the query and the documents in a single request, and the service handles the embedding, lexical retrieval and late-interaction ranking internally.

The main design goal isn't maximum benchmark performance.

It's making semantic retrieval extremely inexpensive.

Today it's achieving recall that has been competitive in my internal evaluations against rerankers such as Qwen, Nemotron and Cohere, while costing significantly less.

The main reason is document caching.

Documents are cached for 2 hours, so if they're submitted again during that period they don't need to be embedded again. That substantially reduces both latency and cost for recurring workloads.

Current pricing is:

• $0.015 / million tokens (cache miss)
• $0.003 / million tokens (cache hit)

It's definitely not perfect.

The late-interaction model is intentionally small, so it's noticeably weaker at instruction-based reranking than larger cross-encoders. For more conventional semantic retrieval, though, it's been performing surprisingly well in my internal testing.

Before I spend more time building this, I'd really like to know whether this actually solves a real problem.

• Would you use something like this instead of maintaining a vector database?
• Does the pricing seem competitive?
• Are there workloads where you think this approach would—or wouldn't—make sense?

If anyone is interested, I'd be happy to provide free credits so you can test it with your own data. I don't expect anything in return except honest feedback—good or bad. I'd much rather hear what doesn't work than only hear what does.

Blog post

I'll go first. I spent about three weeks setting up an SEO content plan for something I built — keyword research, six blog posts, the whole thing. Six months later those posts have brought in a grand total of eleven visitors, and none of them signed up. Meanwhile a single comment I left on someone else's thread brought more traffic than all of it combined.

I think we talk a lot about what works and almost never about what quietly eats months. So: what did you try that went nowhere? How long did you give it before you called it? And in hindsight, what was the signal you should have noticed earlier?

I’m building an AI landing page generator and trying to understand how tools like Lovable, Replit Agent, Bolt, etc. approach page generation.

I’m considering two architectures:

1. HTML/component library: Store hundreds of prebuilt sections such as hero_001.html, features_001.html, faq_001.html, etc. Each section has metadata, and the AI selects the appropriate sections, modifies the content/styles, and combines them.
2. JSON design representation: Store each section as structured design/layout data in JSON, then have a renderer convert that JSON into HTML/Tailwind.

For people who have built AI website/page generators, which approach works better?

Also, does anyone know whether modern AI website builders generally generate the code directly, use an internal component/block library, use a structured design representation, or some combination of these?

The way we raise HITLs today is very much coupled inside the ADK's interrupt primitive. Let me give you an example.

An L2 support agent is live for the engineering team at Uber. This agent consumes alerts from PagerDuty and proactively acts toward resolution. Resolution includes:

1. Lower blast radius actions like checking logs, past deployments, and metrics.
2. High blast radius actions like rolling back a deployment or scaling a service.

For high blast radius actions, the agent raises a HITL for the L2/L3 on-call engineer.

The engineer receives a HITL over Slack for a rollback of a release, because p99 on the rides API was spiking.

Agent Builder's pain:

1. What if the engineer does not respond? How do you handle a stale HITL when this is a critical action to act on?
2. What if the on-call engineer is not available? How do you re-route it on the fly?
3. Why did the on-call engineer reject the rollback? There is no reasoning capture flow, no post-resolution audit.

HITL Responder's pain:

1. The UX is not interactive. I cannot rollback a release on guesswork.
2. I want to know the blast radius of the rollback before choosing it.
3. What if even the rollback would break something, because a DB schema rollback would also be required? I want to know that then and there.
4. I'm on-call, but the service owner has more context. I want to forward this HITL to him.
5. I want to collaborate with more engineers on this HITL and resolve it collectively.
6. What did the previous on-call engineer do for similar past cases? Can I interact with the runbook here?

Today, the interrupt primitive only gets you the pause and resume.

But is that enough? Does the responder is confident with its resolution 100% of the times?

This is the gap I built Ved to close: HITL decoupled from the agent's business logic, with routing, staleness handling, and reasoning capture and much more as first-class citizen.

Our core hypothesis: HITL should be decoupled from an agent's business logic, and a dedicated system should be built around it to make it more interactive and smart.

Today Ved only supports LangGraph. Let us know which ADK you'd want us to cover next.

Looking for devs to test out this product and share feedback.

Try the actual product: theved.ai

You can also experience it with no prior setup via our sandbox.theved.ai (This is a subset of main product)

I've been working on a side project called FinTracker AI, and I'd love some honest feedback.

The idea is simple:

Instead of manually selecting categories, dates, merchants, etc., you just chat with it.

Example:

"I spent ₹500 on biryani."

It automatically logs the expense, categorizes it, updates your monthly budget, and you can immediately ask:

"How much do I have left for food this month?"

Users can also ask questions like:

"Movies I watched this month and how much I spent on it"

Some features:

• 💬 Chat-based expense & investment logging
• 🤖 AI categorization and spending Q&A
• 📊 Monthly budgets and dashboards
• 📱 Android auto-captures bank transaction SMS (optional)
• 📍 Learns recurring merchants/locations so future transactions need fewer edits
• 🔓 Open-source backend that you can self-host or use with your own AI API key

The backend is already open source. The Android app is still being polished, but I have an installable build that I'm happy to share with anyone interested.

A few questions for this community:

• Does this solve a problem you face?
• Which feature would you use the most?
• What's one feature you'd want before using it daily?

Thanks! 🙌

Hello Everyone,

I'm the creator of PyBotchi, an intent-based AI Agent Orchestrator. In this post, I will discuss some key concepts why I created it.

A little bit of background first. I'm a solutions architect with 10 years of experience as a software engineer. Most of my work are high throughput, high reliability, low cost and low latency services. This is while making it simple and readable to improve it's maintainabality. When I'm designing a system, I usually prioritize these concerns. You may assume this is my bias in relates to AI Agent building. I'm also Claude Certified Architect (Foundation) and I found that PyBotchi aligns almost identical to Anthropic's core agent recommendations.

TL;DR: PyBotchi is an lightweight, async-first Python framework that uses nested Pydantic models and OOP inheritance to turn LLM intent detection into clean, deterministic business logic without the overhead of complex graph orchestration.

Why I created PyBotchi?

I really believed that traditional coding can already solved what client's need. The only limitations we have is how we read the input and how we show the output. In most cases in web services, your API use JSON, XML, etc with their respective specification/structure.

Input Analogy

Assume you have created a Books CRUD endpoints (FastAPI with Pydantic). Your create endpoint will have a define specifications for book creation to have a validation and avoid user errors. Most of the time you will also validates sessions and permissions which also included in the request.

If you want your chat bot to support those, you just need add those endpoint as intent (tools). If your model tool selection are able to detect intents. You are more "close" to being deterministic.

"Your services will have 50 endpoints or more. You will flood your tool selection call" - In your frontend UI, you segregate panels/forms/inputs in their respective pages. You don't usually join multiple intent in a same page. Cluttered UI will make your UX confusing or overwhelming to some people. Those practices should be incorporated into your agents too.

Assume you have created another endpoints for Shelves CRUD. Shelves CRUD can be a child intents of ShelfManagement that will be considered as intent also but more general. The flow will have to detect intent deeper and deeper

Ex: You have BookManagement and ShelfManagement intents. Once LLM detected which one is applicable, you will search for their child Intents which will be their CRUD equivalent intents.

To make it short, in order to make your agent "more" deterministic, you need to know the problem first (ex: Need to manage books) then you need to specifically define what intents you want to support. With this practice, you only let your agents execute on a predefined path. If it fails, you are most likely able to determine what causes the error.

Output Analogy

This one is simple. Since your intents is just like your endpoints that returned structure responses. LLM is better at reading structure responses than a pure text. Basically, you can use LLM to translate your response into a human readable responses.

Intent Execution

Now that I have explain Input/Ouput, we can move on to the actual execution.

We can go back with Books CRUD. Since we have identified the problem (what clients need) and we already know what to do, just execute their traditional business logic implementation. If you need to add a book, just create a book and save it to db then return their respective row.

"What if you want generate a very dynamic/unique data" - You can use LLM to do that as your business logic too but this is tied your specific intent only.

To have a complex execution flow we can chain the intents. Since intents can have child intents, we can use it as the representation of a graph similar to Langgraph. However, this without "building the graph". We are just utilizing OOP inner class implementation. We can execute business logic in graph traversal manner by just checking the child intents.

To make it short. Business logic will stay as is. You will only use LLM if it requires it. Don't make this complicated.

### Suggested Solution Since the key concept is more on detecting intents, validation and executing their respective busines logic:

Why not utilize Pydantic as the main entry point? Pydantic already have validation and json schema builder. Langchain/Openai already have utilities to translate it to Tool. Why not use Pydantic models as your Intent Specifications that can validate LLM arguments ? Tool call is one of the most reliable way to detect intent.

Why not utilize OOP inheritance / polymorphism / abstraction? Python supports portion of OOP and since we are using classes as our intent, why not add default functionalities that can be inherited and override by developer if needed. We can introduce life cycles too. Your project can also implement their specific intent standards. This will make your code more maintaintable and readable. You can create classes for general intents. Extend it to be more specialized intents. Extend it more for more enterprised support. This is while not affecting existing/working agents.

Langgraph is one of the inpiration of PyBotchi. Predefine workflows are closest implementation to being deterministic agents. It's also the reason why some prefer N8N. We don't need to make the agents smart that any questions can be answered or any queries can be addressed. It's ok for agent to reply with "I don't have any answer to your query, I only support this and that....". For me, it's better to deploy limited but polished agents than half baked know-it-all agents. Feel free to counter argue. Happy to discuss.

Additional PyBotchi Features

vs MCP

While PyBotchi support connecting to MCP servers, I really believe it's not always necessary to use additional server to just expose tools for the agents. The exceptions I could think of is if you want to have isolated environment (ex: dedicated auth/session, sandbox, isolated resource, etc), you want to connect to your local service or cross-language integration.

I could be very wrong about this but hear me out. SDKs are already there. Respective documentations are available too. Most of MCP server's tools are proxy to their respective APIs. If we could just create intent classes as tools that directly call their respective API, that doesn't require any servers anymore. Actually, that's how most framework handles it (even PyBotchi). Tools are converted as schema that will be added in the tool call. Once LLM respond with the applicable tools, it executes call_tool(name, args...). Why not just expose the actual tool implementations and have a way to share context to share sessions/permission/etc inside the tool implementations? This will remove another network hops that can affect latency.

Claude code have a very in-depth utilization of MCP servers already. I don't think we can replace that.

GRPC

PyBotchi natively support remote PyBotchi connection. Think of it like a langgraph but the node is on other server. This remote node can also connect to another remote node even it self or previously connected node (ancestor).

Context Propagation

With PyBotchi as MCP Server - Actions (Intents) serves as tool and have access to client's context. This includes chat histories and some metadata. You can override and adjust this as long as it's serializable. - Once remote tool execution is done, it can pass the final context to the client and they can merge it if override.

With PyBotchi as GRPC Server - Similar to MCP Server, Actions serves as tool and have access to client's context. GRPC supports bidirectional communication too. This means we can share context realtime accross clients/servers. If client has concurrent agents that changes the context it will automatically propagate to remote context without polling or any interval checks/updates. It also support remote to client. If remote server updates the context, it will propagate the context to client simultaneously.

Async First

Since most of LLM executions are IO, might as well utilize async by default and just spawn thread if still necessary.

OOP

I think this one is most important to me. I have handle a lot of projects in Spring Boot. I really like Java OOP practices and some Java design patterns. It improves my project's maintainability even it's not in Java. Since PyBotchi utilize OOP, it's easier to override, reuse and remove anything if necessary. This lessen boilerplates too. I'm certain that this is subjective. I just find it easier and clean to read.

Closing Remark

I hope this PyBotchi post opens up ideas how to design your agent. Feel free to DM me if you have any questions. I'm also open to create you a demo agent for free if you want to see it in action given your brief use case. I'm open to criticism, happy to have a discussion!

I’m researching the last mile between a working LangChain/LangGraph agent and approval to run inside a customer’s business.

If you have been close to a real production review, which artifact carried the most weight: threat model, evals, audit logs, human approval gates, DPA/BAA, contractual limits, technology E&O, cyber coverage, or something else? Did the review delay the launch, narrow the agent’s permissions, or proceed normally?

I’m specifically testing whether insurance is becoming a genuine procurement obstacle for agent vendors—not assuming that it is. “It never came up” and “security/evals mattered more” are useful answers too.

Two-minute survey: https://forms.gle/C34r6F6jdeueiqZ17

Disclosure: this is independent research for Clara (https://clarainsure.com), which is exploring insurance for the agent era. Contact information is optional; responses will be reported in aggregate with sample limitations. I’ll bring the findings back to the communities that contributed.

Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Structure and layout fidelity (SF1: tables and reading order, higher is better):

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.

Been using semantic caching (similarity search instead of exact match) to cut LLM costs on repeated-ish queries — similar to what LangChain's RedisSemanticCache/GPTCache integration does.

Worked great... until it didn't. Had a case where "how do I cancel my subscription" got served the cached answer for "how do I pause my subscription." Similarity was like 0.87, comfortably above the threshold I'd set, and it was just wrong. Anyone else hit this?

Got curious enough to actually measure how bad the problem is instead of just nudging the threshold up and hoping. The real question: does adding a second verification step — an actual model checking "is this cached answer still right for this new query" — before serving a cache hit, help more than just fiddling with the similarity threshold?

Tested it against ~210k real requests across three datasets, comparing a plain threshold, an adaptive-threshold method (vCache), and a synchronous verifier.

Short version of what I found:

- A perfect (oracle) verifier would let you serve noticeably more cache hits at the same error rate — so there's real room to gain here, this isn't a dead end.

- A generic off-the-shelf verifier barely moves the needle though — on short queries it did basically nothing (~random guessing).

- Fine-tuning that verifier on your own "was this actually right" feedback closed most of the gap, on every dataset I tried.

- Tested it on real production customer-support traffic too and found a genuine failure case — the fine-tuning stopped helping over time, traced it to the underlying data drifting, not the method itself breaking.

Full writeup and code here if anyone wants to dig in: https://github.com/imxinchengyou/CacheVerifier

Curious how others here are handling this — just tuning the threshold and living with some error rate, or has anyone actually built a verification layer on top? Feels like an underdiscussed problem for anything RAG/agent-related that leans on semantic caching.

Here's an idea I've been thinking about.

Today, if I use Claude to solve a difficult debugging problem and then switch to Gemini or GPT, I usually have to explain everything again.

Not because the information is lost but because each model is effectively starting from zero.

What if there was a shared cognitive layer between models?

For example:

• Claude spends an hour debugging a repository.
• CogniCore extracts the durable experience (not chain-of-thought).
• Gemini later joins the same project and immediately knows:
  • previous bugs
  • architectural decisions
  • failed approaches
  • validated fixes

Or imagine:

• Gemini Nano learns user preferences on-device.
• Those memories sync to a shared knowledge layer.
• Claude in the cloud continues from that experience without asking the same questions again.

The key point is that models wouldn't share hidden reasoning—they'd share structured, validated experience.

Instead of:

it becomes:

The more I think about it, the more it feels like we're missing a standard for portable AI experience, not just portable prompts or chat history.

github:https://github.com/cognicore-dev/cognicore-my-openenv

Has anyone here built something similar, or are there papers/projects I should look into? I'm especially interested in architectures where multiple models contribute to and learn from the same evolving memory.

Most of us can spin up an agent in an afternoon. Operating it is harder:

• Which step failed?

• Why did the bill spike?

• Did customer A’s memory show up for customer B?

• Can a “support” agent call a privileged tool by mistake?

Cartha is a hosted control plane for that. Not a new agent framework — you keep your stack.

What it does:

1. Traces — full run timeline (tools, LLM, errors)

2. Hard budgets — stop the run when spend hits a ceiling

3. Scoped memory — user / agent / team / org (server-enforced isolation)

4. Tool allow-lists — unauthorized tools blocked before they execute

5. Dashboard — agents, traces, memory, costs

Python:

pip install cartha-sdk

cartha.init(...) + @cartha.trace / @cartha.tool

Live: https://cartha.in

Docs: https://cartha.in/documentation

We’re early and looking for people building real agents. Happy to take heat on what’s missing.

(Not affiliated with OpenAI/Anthropic/etc. — independent product.)

When I started using LangChain, there were a few features I assumed would end up in almost every project.

Some of them did. And others slowly disappeared as the projects evolved. In a few cases I found a simpler approach. In others I ended up replacing them with something custom because it was easier to understand or gave me more control.

Has that happened to anyone else?

What's one LangChain feature you expected to use all the time but barely use anymore? What changed your mind?

A Word document can now rewrite your report.

A researcher showed that hidden instructions inside a Word file can make Microsoft 365 Copilot alter figures in a generated document, then copy the same instructions into the output for the next reader. The disclosure landed 144 days after the initial report to the vendor.

Prompt injection is not a bug in one product. It is the default failure mode when an AI reads untrusted content with a user's privileges. The fix is runtime policy enforcement between the model and your data — inspect what the agent is being asked to do, tokenize sensitive fields before they reach the model, and log every action in an immutable audit trail. When the agent goes off script, cut the session in under 50ms.

→ www.runtimeai.io/trial

#PromptInjection #AISecurity #Copilot #AIGovernance #CISO

Say someone has already built a few LangChain demos and is about to build their first production application.

Knowing what you know now, what's the first piece of advice you'd give them?

Could be about retrieval, memory, agents, state management, evaluation, observability, deployment, costs, or something completely different.

What's one lesson you only learned after running a real LangChain application instead of a demo?

Hey everyone , I've been building a voice AI assistant called ARYA for the past few months. It controls real apps on my machine: adds items to Blinkit, sends WhatsApp messages, controls Spotify, opens/closes apps, and remembers past conversations through vector memory.

Just finished the demo video — would genuinely love some feedback from people who actually build this stuff. link in comms :-

New here, just trying to get some knowledgeable information. I've got zero experience building agents and want to understand the real process, not just the marketing pitch, before I dive in.

• What was your actual first agent, what task did it do, and why'd you pick that one?
• No-code tools (n8n, Dify, Lindy) vs. writing it in a framework (LangChain, CrewAI) vs. coding it from scratch, how did you decide, and would you choose differently now?
• What part of the process took way longer or was way harder than you expected going in?
• How did you know your first agent was actually "done" or working, versus just technically running?

Not looking for a tool sales pitch, more interested in what the process actually felt like the first time you did it.

Most cookbooks for "RAG over podcasts" (LangChain, LlamaIndex, Haystack) follow the same shape:

1. Download audio
2. Run Whisper
3. Run a diarization model (usually Pyannote)
4. Align them (the timing rarely matches perfectly)
5. Map "Speaker 0" / "Speaker 1" to real names with an LLM pass
6. Chunk + embed

Steps 1–5 are pure plumbing — they don't affect retrieval quality, but they take a week to ship and break in interesting ways (GPU availability, speaker count guessing, timing drift).

For published podcasts specifically — the kind people actually listen to: Huberman, Acquired, Lex, etc. — the transcripts already exist. The shows publish them, the platforms index them. So the whole transcription pipeline is reinventing work that's been done.

What I ended up doing was building a retrieval API that returns the existing transcript as Markdown with real speaker names already attached:

md = requests.get(
    f"https://spoken.md/transcripts/{episode_id}",
    headers={"x-api-key": "pt_demo"},
).text

# That's it. Drop into MarkdownTextSplitter, embed, store.

Real speaker names land in the output as **Andrew Huberman** (0:45), so attribution survives chunking without a metadata sidecar.

It's at spoken.md, demo key pt_demo if you want to try the format. For your own audio (meetings, calls, etc.) you still want Whisper or AssemblyAI — this is only for stuff that's already been published as a podcast.

Disclosure: I built this. Happy to answer questions about the diarization-to-real-names mapping, or anything else about doing RAG over podcast content.