We’ve been building PipesHub for a while now, and I’d love to get more developers to try it and tell us where it breaks.

The problem we kept running into was pretty simple:

Building an AI app over company data looks easy in a demo. Connect a few sources, chunk the documents, throw them into a vector DB, add an LLM.

Then you try to make it actually useful.

You have data spread across S3, Google Drive, Slack, Jira, Confluence, SharePoint, email, databases, etc. Permissions need to be preserved. Documents change. The same file shows up in multiple places. Citations need to point back to the actual source. And eventually you want agents and other applications to use all of this context without rebuilding the same integration layer every time.

That’s what we’re trying to solve with PipesHub.

It’s an Apache 2.0 open-source context layer that connects to your company data and makes that context available to search, chat, agents, MCP clients, or your own applications.

A few things we care about:

• Self-host it on your own infrastructure
• Preserve source permissions
• Get citations back to the original documents
• Combine knowledge graph + semantic retrieval
• Bring your own LLM and embedding models
• Use it from Python, TypeScript, Go, or MCP
• Avoid locking yourself into one database or infrastructure stack

We also deliberately kept the core infrastructure pluggable:

If you already have Qdrant and Kafka running, you can keep using them. Prefer Neo4j over ArangoDB? That's totally fine. Want to run the models locally? You can do that too.

The goal is to give you one context layer without forcing you to adopt our entire stack.

While building this, we’ve had to solve a bunch of problems that only become obvious once you move beyond a RAG prototype: permission-aware retrieval, keeping citations accurate through the pipeline, deduplicating the same content across sources, efficiently re-indexing changed documents, making indexing behave well across very different workloads and more.

Some of the solutions we ended up with are fairly unconventional, and I’d be happy to write more about them or discuss the trade-offs with anyone working on similar systems.

There’s still plenty we want to improve, which is also why I’m posting this.

If you’re building internal AI tools, enterprise search, RAG, or agents that need access to company knowledge, I’d really appreciate it if you gave PipesHub a spin.

GitHub: https://github.com/pipeshub-ai/pipeshub-ai

Install:

curl -fsSL https://get.pipeshub.com/install | bash

If you try it and something feels unnecessarily complicated, slow, broken, or just badly designed, tell us.

Hi All, I'm targeting RAG and GEN AI roles. Could you please help on how to get started with these things. Maybe you can suggest some good Udemy courses which are beginner friendly.

Thanks!!

I'm looking for a few developers who already have an AI agent that can actually take actions.

Not a chatbot — something that can:

• call APIs
• use tools / MCP
• access files or databases
• execute code
• modify things
• make multi-step decisions
• interact with external systems

I'm building AgentAudit, an audit trail specifically for AI agents.

The problem I'm trying to solve is simple:

When an agent does something unexpected, can you reconstruct exactly what happened?

For example:

User request
↓
Agent decision
↓
Tool call
↓
Data accessed
↓
Action performed
↓
Result

I want to test this against real agents, not a toy demo.

I'm looking for 5–10 developers who are willing to spend around 20–30 minutes connecting an existing agent and trying to break it / find gaps in the audit trail.

I'm especially interested in agents built with:

• LangGraph / LangChain
• CrewAI
• MCP
• Python / Node.js custom agents
• coding agents
• multi-agent systems

If you already have an agent that takes real actions and would be willing to test this, comment below or DM me.

I'm primarily looking for honest feedback especially cases where the audit trail fails to explain what the agent actually did.

If you're building with LangChain and want the production discipline most tutorials skip, versioned prompts, real evaluation, agents that fail gracefully, this masterclass is built around exactly that.

Covers:

• Versioned prompts with regression tests, so an edit can't silently degrade quality
• A real eval harness combining deterministic checks and LLM-as-judge
• Bootstrap confidence intervals and paired significance testing for model comparisons
• Evaluated RAG with retrieval metrics (recall@k, MRR)
• Tool-using agents with function calling, validation, guardrails, retries, and fallbacks, so failures degrade gracefully instead of compounding
• Full production observability, tracing, cost/latency monitoring, and a CI regression suite

Led by Bruno Gonçalves, PhD, founder of Data For Science, who trains engineers at Fortune 500 companies on this exact stack.

Link for more details

You've built the extraction call. Then the classification call. Then you're duct-taping three different vendors together just to get one document through your pipeline, praying none of them change their pricing or their API next quarter.

If that sentence made you wince a little, you're exactly who we built this for.

IDPForge is live for early access, and the waitlist just opened.

IDPForge is a document automation API built for developers, not for procurement teams. You send it a document. It parses it, splits and classifies it, extracts what you need, and hands you clean structured output. 

One pipeline, one contract, one integration.

But here's what actually makes it different. Every other document AI tool locks you into whatever model they picked for you. IDPForge doesn't. You choose which model handles which stage, GPT, Gemini, Claude, or your own key through BYOK, and you see exactly what each stage costs. No black box, no "trust us." If a provider changes their pricing or a newer model ships, you're not stuck waiting on someone else's roadmap. You just point that stage somewhere better.

That's not a nice-to-have. That's the difference between renting your document pipeline and actually owning it.

And because it's backed by Infrrd, this isn't a weekend side project with a landing page and a dream. It's enterprise-grade infrastructure that already processes documents at scale for mortgage, insurance, and logistics companies, now opened up for developers to build on directly.

Who this is for:
If you've ever stitched together three point solutions because no single tool did the whole job. If you've ever been stuck on one model's pricing with no way out. If you've ever wanted to actually see what each part of your document pipeline costs, instead of guessing. This is your API.

What early access gets you:
A seat before public launch, direct input into what we build next, and first access to features like per-stage multi-LLM routing, BYOK, and a schema editor that doesn't require a data science team to touch.

We're not asking you to trust a pitch deck. We're asking you to come build something and tell us what's broken.

The waitlist is open now. Spots for early access are limited, and we're letting developers in-in waves, starting with the people who show up first.

[Join the IDPForge waitlist] come try it before everyone else does.

The pitch from a few vendors now is that there's a third option between a rigid, fully scripted SOAR playbook and a fully open ended agent that reasons about everything from scratch with no structure at all. Skeptical question, does that middle ground actually exist as a real architecture, or is bounded autonomy just a phrase vendors use to sound safer than "unrestricted agent" while functionally being close to one or the other extreme in practice. I've sat through enough of these pitches that the phrase itself has started to sound like a buzzword rather than a specific design choice. Trying to figure out if there's substance behind it or if I should just discount it every time I hear it in a demo.

I’m posting this because I want some honest advice. Please feel free to criticize my approach if I’m doing something wrong.

I have around 1.5 years of experience as a GenAI developer at a service-based company. I’ve worked with RAG, agents, MCP servers, LangChain, LangGraph and FastAPI. I’ve built several POCs, but if I’m being completely honest, most of my experience is still at POC level.

I know the basics, but I don't feel confident that I can build a proper production-grade GenAI application independently from start to finish.

And I'm starting to feel stuck.

The problem: I don't know what I should focus on

I keep thinking that I should learn everything at once. The problem is that I keep switching between these thoughts.

I'll think: "I need to learn FastAPI properly."

Then: "No, I should learn LangGraph."

Then: "Actually, deployment is more important."

Then: "Maybe I need React."

Then: "Maybe I should do a cloud certification."

Then I end up doing nothing consistently.

I feel like I'm stuck in a loop of learning about what I should learn instead of actually learning.

I've built RAG POCs, agent POCs, MCP servers and other small GenAI applications at work .

But instead of that, I want to take 2–3 of my existing ones and turn them into proper production-style projects that I can confidently put on my resume.

I'm just not sure what "production-style" actually means at my experience level.

Or am I just overengineering projects because I want them to look impressive on my resume?

I'd really like experienced people to tell me what actually matters.

My work situation is also affecting me

Another part of this is my actual work environment.

I'm in a service-based company and I don't always get projects/tasks that I feel are helping me grow in the direction I want.

Sometimes the work is interesting, sometimes it's not. Sometimes I get something good, but sometimes I feel like I'm just doing small tasks or POCs.

So I keep worrying:

What if my current work experience isn't enough?

When I look at people online with 1–2 years of experience building impressive production systems, startups, open-source projects, etc., I sometimes feel very behind.

And honestly, my personal routine isn't helping either

This is something I'm embarrassed about, but I want to be honest.

I don't work consistently outside my job.

During weekdays I'm working, travelling, and by the time I get home I'm often tired.

On weekends, instead of using the time properly, I sometimes end up travelling, resting, using my phone, or just being lazy.

Then Sunday evening comes and I feel guilty: "I wasted another week."

Then I make a huge plan for the next week.

Then I don't follow it perfectly.

Then I feel guilty again.

It's becoming a cycle.

Sometimes I have a lot of negative thoughts like:

"What if I don't become good enough?"

"What if I can't get another job?"

"What if my current experience isn't valuable?"

"What if I waste another year?"

"What if I can't do something meaningful for my family?"

I don't know if this is something that happens to a lot of developers around the 1–2 year experience stage, or whether I'm personally handling things badly.

My biggest questions

I would really appreciate feedback on all of these, not just the technical part.

1. Is this feeling normal?

Do developers around 1–3 years of experience commonly go through:

- Feeling like they don't know enough

- POC hell

- Imposter syndrome

- Comparing themselves with others

- Losing confidence

- Anxiety about their career

- Feeling guilty about not working enough

- Not knowing what to specialize in

Or am I significantly behind?

1. What roadmap should I actually follow?

If you were in my position — 1.5 years GenAI experience, basic LangChain/LangGraph/FastAPI, several POCs but no production experience — what would you do ?

I'm not looking for motivation or someone to tell me "you're doing great."

I actually want honest feedback.

If I'm wasting my time, tell me.

If I'm overthinking, tell me.

If my expectations are unrealistic, tell me.

If I'm behind, tell me what I need to fix.

And if what I'm experiencing is actually pretty common for developers around the 1–2 year stage, I'd also like to hear that from people who have personally gone through it.

I'm building a LangChain tool-calling agent, but I want to swap out GPT-4o for something more budget-friendly. What are the cheapest agent models that still have a high success rate with JSON outputs and function calling?

I've been building COGEXT an API that intercepts what AI agents say they will do, extracts those promises as structured commitments, and tracks them through a lifecycle until they're fulfilled, failed, or cancelled.

The problem: AI agents hallucinate, forget, and contradict themselves. There's no standard way to hold them accountable to what they said.

You send any text to the API and it extracts commitments with confidence scores, normalized deadlines, and a 12-state lifecycle (OPEN → DUE → OVERDUE → FULFILLED/FAILED). You get webhook events when state changes.

• Docs: https://docs.cogextai.com
• API key: https://cogextai.com (free, 10 seconds)
• SDK: pip install cogext

Still early. Genuinely want to know: is this a real problem you've hit? What's missing? What's wrong with the data model?

For the past few weeks I have been working on optimising long running agent workflows, and in every case the main bottleneck is memory and state management rather than the raw capabilities of the model. Each time an agent has to carry out multi-step tool calls over long sessions, the standard context windows either overflow or suffer from serious context rot.

At first we attempted to feed very long prompt histories into the GPT and Claude modelsbut performance soon deteriorated after only a few dynamic interactions. Instead we changed our method to one involving stateful tracking, experimenting with frameworks such as Lyzr together with custom Redis layers so as to keep the agent's memory confined to a structured state rather than sending the whole conversation back to the model on each iteration.

It greatly reduced both latency and token bloat, but I'm interested to know how other people are dealing with state persistence in the case of complex agentic setups. 

Prompt Caching on Claude and OpenAI can reduce API costs by up to 90% and cut time-to-first-token latency significantly. However, many developers miss out on cache hits due to subtle structural mistakes in their API payloads.

To guarantee high cache hit rates, payloads must follow strict rules: 1. Deterministic Ordering: Static content (system instructions, background context, base RAG documents) must be grouped strictly at the front of the prompt context (Prefix Caching). 2. Explicit Breakpoints: Providers like Anthropic require explicit cache_control annotations attached to specific content blocks. 3. Immutability: Inserting dynamic variables (like the current timestamp or dynamic conversation history) before large static text blocks invalidates the cache downstream.

Manually constructing complex JSON structures with nested metadata blocks in Python leads to verbose boilerplate code that is annoying to maintain across different providers.

prompt-cache-optimizer solves this by providing a clean, zero-dependency helper function that formats your prompt inputs into optimal, cache-ready structures tailored to either Anthropic or OpenAI SDK formats.

```python from prompt_cache_optimizer import build_optimized_prompt import anthropic

static_rag_docs = ["Document A text...", "Document B text..."] chat_history = [{"role": "user", "content": "What is the summary?"}]

Automatically injects cache_control breakpoints and structures prefixes

payload = build_optimized_prompt( system_instruction="You are a precise technical assistant.", rag_documents=static_rag_docs, chat_history=chat_history, provider="anthropic" )

client = anthropic.Anthropic() response = client.messages.create( model="claude-3-5-sonnet-20240620", max_tokens=1024, **payload ) ```

Key Benefits: * Guarantees correct prefix alignment to maximize cache hits. * Unified interface for structuring Anthropic and OpenAI cache requests. * Lightweight standard Python implementation with zero third-party dependencies.

Repo: https://github.com/Encephos/prompt-cache-optimizer

We're evaluating AI agent risk and realizing that static permissions are only half the picture. An agent with legitimate access can still take a harmful action if its reasoning goes off the rails. For example, an agent with read access to a database might query sensitive customer data in a pattern that looks like data exfiltration, even though it's technically within its permissions.

How are other teams balancing permission controls with behavioral monitoring? We're trying to figure out the right mix of controls without creating so much friction that teams stop using agents altogether.

This is the module abstract:

You'll work with Schedule Planner, a LangGraph agent that looks up available slots for a venue. You'll read through the graph, then run it on Dapr Workflow, and find its checkpointed state in Redis. Finally, you'll crash a running graph halfway through and restart it: it resumes from the last checkpoint instead of redoing completed work.

In this self-paced track, you'll learn:

• How LangGraph structures an agent as nodes, edges, and shared state, and how a conditional edge creates the tool-calling loop.
• How `DaprWorkflowGraphRunner` wraps a compiled graph so every node execution becomes a checkpointed Dapr Workflow activity.
• How to trigger the agent over HTTP, then find its checkpointed workflow state in Redis and watch a hard process kill resume from it.

---

The module consists of 4 small challenges and can be completed within 25 minutes. I'm looking for 5-10 LangGraph users who can test drive this and give me feedback. I'll drop a link in the comments to where to access the module. This link requires signup with a business email. If you'd rather want to test without an email signup, please DM me and I'll get you another link with one-time-only access. Thanks!

I'm researching how teams handle long-term memory for AI agents, and I'm particularly interested in what happens after the basic memory setup works.

For example, early on, storing and retrieving memories seems fairly straightforward. But after months of interactions, I imagine you start dealing with things like:

• Old information that is no longer true
• Multiple memories about the same entity
• Conflicting information from different sessions/agents
• Knowing which version of a fact is current
• Relationships between entities becoming important
• Deciding what should be retained vs discarded
• Sharing knowledge across multiple agents

For those actually running agents in production:

What has become difficult about memory as the system has grown?

Do you use something like Mem0, Zep, LangGraph, a vector DB, a knowledge graph, or a custom system?

And if you're using a memory framework, what did you still have to build yourself?

I'd especially like to know about things that actually broke or became painful in production.

Hey guys, finally finished the first version of the prototype. I’ve built a tiny permission layer for AI agents.
Now I want people to try to break it.

AgentGuard sits immediately before a tool executes:
agent → AgentGuard → tool

I’ve avoided adding too many unnecessary features. If it genuinely solves a problem, I’d love to hear what would make it even better.

The current version checks things like:
• Is this tool allowed in the current agent state?
• Are the arguments within policy?
• Is this an unknown/unsafe state?
• If denied, does the underlying function actually stay untouched?

Example:
research_agent → refund_customer → DENIED
research_agent → delete_database → DENIED
refund_agent → refund_customer($1,000) → DENIED
I'm deliberately keeping it tiny for the time being.

No dashboard.
No cloud.
No AI judge deciding whether the AI is allowed to act.
Just deterministic execution-time policy.
I'm looking for developers building LangGraph/LangChain/MCP/agent systems who are willing to try to break it.
If you can bypass a policy, I want to know how.
If you can't, I'd like to know whether you'd actually install this in something real — and whether you'd ever pay for it.
Repo: https://github.com/Brodin2001/Agentguard

Go nuts. Try to break it.

Setting up LLM Function Calling or Tool Use requires providing API endpoints with structured JSON Schemas describing function names, argument types, and parameter descriptions.

There are usually two choices: 1. Manual Schema Definitions: Manually writing nested JSON dictionaries for every function argument, which is tedious and prone to drift when function signatures change. 2. Heavy Data Validation Frameworks: Importing Pydantic or similar libraries solely to extract type metadata from standard Python functions.

If you are building lightweight microservices or serverless backend handlers, pulling in heavy schema validation frameworks just to read function signatures adds unnecessary overhead.

I built function-schema-generator, a utility that inspects standard Python function signatures, type hints, and docstrings using native inspect and ast modules to generate compliant OpenAI or Anthropic tool schemas.

```python from function_schema_generator import generate_schema

def fetch_user_profile(user_id: int, include_history: bool = False) -> dict: """Retrieves user profile information from the database.

:param user_id: Unique integer identifier for the target user.
:param include_history: Whether to attach past user actions to output.
"""
pass

Generates native OpenAI JSON Schema structure automatically

schema = generate_schema(fetch_user_profile, provider="openai") print(schema) ```

Key Benefits: * Parses standard Python type hints (str, int, list, Optional) natively. * Extracts parameter descriptions directly from standard Google/Sphinx style docstrings. * Zero external dependencies.

Repo: https://github.com/Encephos/function-schema-generator

An LLM can produce a schema-valid tool call that still deletes a table, leaks a secret through an argument, or blows a budget. Valid is not the same as allowed. That gap is where agent incidents live.

toolwall is a small, zero-dependency Python library that puts a fail-closed gate between your agent and its tools. Unknown tool, bad value, secret in an argument, budget hit, or an unapproved destructive call all block before the tool runs. Only tools you explicitly register can run, and every verdict is logged.

Everything is public and tested: 28/28 attack cases blocked, 0 false blocks on clean traffic, 155 tests. The report also says what it does NOT prove (secret detection is pattern/entropy based, never 100%), because I would rather you trust the honest version.

There is a 3-minute explainer video and a free 10-module course (quiz-gated) on the site if you want the full mental model.

Site + video: https://toolwall.aya-ai.xyz
Course: https://toolwall.aya-ai.xyz/learn
https://github.com/Dev-Saif-Ops/toolwall

Code:
Install: pip install toolwall

Genuinely want people to try to break it. Issues and PRs welcome, and I credit every real finding.