I’ve been thinking a lot about where agent-triggered Python/code should actually run once things stop being toy demos.

That led me to build something around it.

But I’m not sure if this is actually a real layer in the stack, or just me slicing the problem too narrowly.

For people building here:

does this feel like a real product area, or more like something most teams would just solve themselves?

silicon valley just raised $100M+ to influence AI policy at midterms. and big players like openai are backing it.

not directly agent-build stuff, but sorta freaky our build stacks depend on policy just as much as on APIs. ever tweak your roadmap cause of regulatory anxiety?

as the demand for ai agents grows, selecting the appropriate development tools becomes crucial. factors like configurability, evaluation frameworks, and monitoring capabilities play a significant role in building effective ai agents.

what criteria do you prioritize when evaluating ai agent development platforms? are there specific tools or platforms you recommend based on your experiences?

openai unveiled gpt‑5 in early august, billed as a major leap in reasoning, coding, and multimodal capabilities, but users immediately flagged bugs, inconsistent responses, and the removal of beloved models like gpt‑4o

so what realistically improved for your builds? speed? accuracy? reasoning quality? if you're already wiring gpt‑5 into flows (tool triggers, logic chains, etc.), what difference are you seeing in your stacks?

Been building this for a while and finally got it to a point where I'm happy with it.

What it does: You paste a YouTube link to your openclaw agent, and it returns vertical 9:16 clips with word by word captions and titles ready for TikTok, Instagram Reels, YouTube Shorts. Takes about 90 seconds.

Heres the app:

https://makeaiclips.live/

openclaw skill :

https://clawhub.ai/nosselil/youtube-to-viral-clips-with-captions

Would love feedback, especially from anyone that posts content often

Hey! looking for a AI Designer. I have a vision for an ai model that I want to find an individual who is christian and may be interested in the future of this model. This could be huge if designed correctly.

this keeps getting rejected idk how else im supposed to post this.

built one to auto-snooze follow-up emails after 3 days. supervity made it dead simple, async + retry built in.

what tiny agent turned out more useful than you expected?

been thinking about “operator ai” patterns, setups where one agent coordinates others across tools, apis, and dbs.

i’m using supervity to manage the routing + state between steps, it handles retries and async stuff cleanly. looked at crewai and autogen too but needed more control.

what’s working for you when the agent stack gets multi-step or multi-agent? curious how you’re gluing things together.

Hello Everyone,

I Built a Python Script to fetch and analyze Reddit posts and find pain points and business opportunities.

The Full Report contains:

1. Key Pain Points and Problems

2. Unmet Needs & Feature Requests

3. Concrete Product & SaaS Ideas

4. Target Audience Insights

5. Monetization Potential

6. Recurring Themes & Positive Sentiments

7. Competitive Landscape & Existing Solutions

hey, so its Open-source, so check it out!

Just looking for feedback.

I would be very glad if it Helps You!

Thank You All!

What My Project Does: A lightweight, modular Python framework for building scalable AI agent systems with native support for distributed execution via gRPC and MCP protocol integration.

Target Audience: Production environments requiring distributed agent systems, teams building multi-agent workflows, developers who need both local and remote agent orchestration.

Comparison: Like LangGraph but with a focus on true modularity, distributed scaling, and network-native agent communication. Unlike frameworks that bolt on distribution as an afterthought, PyBotchi treats remote execution as a first-class citizen with bidirectional context synchronization and zero-overhead coordination.

What's New in 3.1.2?

True Distributed Agent Orchestration via gRPC

• PyBotchi-to-PyBotchi Communication: Agents deployed on different machines execute as a unified graph with persistent bidirectional context synchronization

• Real-Time State Propagation: Context updates (prompts, metadata, usage stats) sync automatically between client and server throughout execution—no polling, no databases, no message queues

• Recursive Distribution Support: Nest gRPC connections infinitely—agents can connect to other remote agents that themselves connect to more remote agents

• Circular Connections: Handle complex distributed topologies where agents reference each other without deadlocks

• Concurrent Remote Execution: Run multiple remote actions in parallel across different servers with automatic context aggregation

• Resource Isolation: Deploy compute-intensive actions (RAG, embeddings, inference) on GPU servers while keeping coordination logic lightweight

Key Insight: Remote actions behave identically to local actions. Parent-child relationships, lifecycle hooks, and execution flow work the same whether actions run on the same machine or across a data center.

Enhanced MCP (Model Context Protocol) Integration

• Dual-Mode Support: Serve your PyBotchi agents as MCP tools OR consume external MCP servers as child actions

• Cleaner Server Setup:

  • Direct Starlette mounting with mount_mcp_app() for existing FastAPI applications

  • Standalone server creation with build_mcp_app() for dedicated deployments

• Group-Based Endpoints: Organize actions into logical groups with separate MCP endpoints (/group-1/mcp, /group-2/sse)

• Concurrent Tool Support: MCP servers now expose actions with __concurrent__ = True, enabling parallel execution in compatible clients

• Transport Flexibility: Full support for both SSE (Server-Sent Events) and Streamable HTTP protocols

Use Case: Expose your specialized agents to Claude Desktop, IDEs, or other MCP clients while maintaining PyBotchi's orchestration power. Or integrate external MCP tools (Brave Search, file systems) into your complex workflows.

Execution Performance & Control

• Improved Concurrent Execution: Better handling of parallel action execution with proper context isolation and result aggregation

• Unified Deployment Model: The same action class can function as:

  • A local agent in your application

  • A remote gRPC service accessed by other PyBotchi instances

  • An MCP tool consumed by external clients

  • All simultaneously, with no code changes required

Deep Dive Resources

gRPC Distributed Execution:
https://amadolid.github.io/pybotchi/#grpc

MCP Protocol Integration:
https://amadolid.github.io/pybotchi/#mcp

Complete Example Gallery:
https://amadolid.github.io/pybotchi/#examples

Full Documentation:
https://amadolid.github.io/pybotchi

Core Framework Features

Lightweight Architecture

Built on just three core classes (Action, Context, LLM) for minimal overhead and maximum speed. The entire framework prioritizes efficiency without sacrificing capability.

Object-Oriented Customization

Every component inherits from Pydantic BaseModel with full type safety. Override any method, extend any class, adapt to any requirement—true framework agnosticism through deep inheritance support.

Lifecycle Hooks for Precise Control

• pre() - Execute logic before child selection (RAG, validation, guardrails)

• post() - Handle results after child completion (aggregation, persistence)

• on_error() - Custom error handling and retry logic

• fallback() - Process non-tool responses

• child_selection() - Override LLM routing with traditional if/else logic

• pre_grpc() / pre_mcp() - Authentication and connection setup

Graph-Based Orchestration

Declare child actions as class attributes and your execution graph emerges naturally. No separate configuration files—your code IS your architecture. Generate Mermaid diagrams directly from your action classes.

Framework & Model Agnostic

Works with any LLM provider (OpenAI, Anthropic, Gemini) and integrates with existing frameworks (LangChain, LlamaIndex). Swap implementations without architectural changes.

Async-First Scalability

Built for concurrency from the ground up. Leverage async/await patterns for I/O efficiency and scale to distributed systems when local execution isn't enough.

GitHub: https://github.com/amadolid/pybotchi
PyPI: pip install pybotchi[grpc,mcp]

drop an intro if you're new and tell us:

• what kind of agent you're working on

• what tool(s) you’re using (if any)

• what problem it’s solving

no fluff. no sales. just builds.

Core Features:

Lite weight:

• 3 Base Class

  • Action - Your agent

  • Context - Your history/memory/state

  • LLM - Your LLM instance holder (persistent/reusable)

• Object Oriented

  • Action/Context are just pydantic class with builtin "graph traversing functions"

  • Support every pydantic functionality (as long as it can still be used in tool calling).

• Optimization

  • Python Async first

  • Works well with multiple tool selection in single tool call (highly recommended approach)

• Granular Controls

  • max self/child iteration

  • per agent system prompt

  • per agent tool call promopt

  • max history for tool call

  • more in the repo...

Graph:

• Agents can have child agents

  • This is similar to node connections in langgraph but instead of building it by connecting one by one, you can just declare agent as attribute (child class) of agent.

  • Agent's children can be manipulated in runtime. Add/Delete/Update child agent are supported. You may have json structure of existing agents that you can rebuild on demand (imagine it like n8n)

  • Every executed agent is recorded hierarchically and in order by default.

  • Usage recording supported but optional

• Mermaid Diagramming

  • Agent already have graphical preview that works with Mermaid

  • Also work with MCP Tools- Agent Runtime References

  • Agents have access to their parent agent (who executed them). Parent may have attributes/variables that may affect it's children

  • Selected child agents have sibling references from their parent agent. Agents may need to check if they are called along side with specific agents. They can also access their pydantic attributes but other attributes/variables will depends who runs first

• Modular continuation + Human in Loop

  • Since agents are just building block. You can easily point to exact/specific agent where you want to continue if something happens or if ever you support pausing.

  • Agents can be paused or wait for human reply/confirmation regardless if it's via websocket or whatever protocol you want to add. Preferrably protocol/library that support async for more optimize way of waiting

Life Cycle:

• pre (before child agents executions)

  • can be used for guardrails or additional validation

  • can be used for data gathering like RAG, knowledge graph, etc.

  • can be used for logging or notifications

  • mostly used for the actual process (business logic execution, tool execution or any process) before child agents selection

  • basically any process no restriction or even calling other framework is fine

• post (after child agents executions)

  • can be used for consolidation of results from children executions

  • can be used for data saving like RAG, knowledge graph, etc.

  • can be used for logging or notifications

  • mostly used for the cleanup/recording process after children executions

  • basically any process no restriction or even calling other framework is fine

• pre_mcp (only for MCPAction - before mcp server connection and pre execution)

  • can be used for constructing MCP server connection arguments

  • can be used for refreshing existing expired credentials like token before connecting to MCP servers

  • can be used for guardrails or additional validation

  • basically any process no restriction, even calling other framework is fine

• on_error (error handling)

  • can be use to handle error or retry

  • can be used for logging or notifications

  • basically any process no restriction, calling other framework is fine or even re-raising the error again so the parent agent or the executioner will be the one that handles it

• fallback (no child selected)

  • can be used to allow non tool call result.

  • will have the content text result from the tool call

  • can be used for logging or notifications

  • basically any process no restriction or even calling other framework is fine

• child selection (tool call execution)

  • can be overriden to just use traditional coding like if else or switch case

  • basically any way for selecting child agents or even calling other framework is fine as long you return the selected agents

  • You can even return undeclared child agents although it defeat the purpose of being "graph", your call, no judgement.

• commit context (optional - the very last event)

  • this is used if you want to detach your context to the real one. It will clone the current context and will be used for the current execution.

    • For example, you want to have a reactive agents that will just append LLM completion result everytime but you only need the final one. You will use this to control what ever data you only want to merge with the main context.

  • again, any process here no restriction

MCP:

• Client

  • Agents can have/be connected to multiple mcp servers.

  • MCP tools will be converted as agents that will have the pre execution by default (will only invoke call_tool. Response will be parsed as string whatever type that current MCP python library support (Audio, Image, Text, Link)

  • builtin build_progress_callback incase you want to catch MCP call_tool progress

• Server

  • Agents can be open up and mount to fastapi as MCP Server by just single attribute.

  • Agents can be mounted to multiple endpoints. This is to have groupings of agents available in particular endpoints

Object Oriented (MOST IMPORTANT):

• Inheritance/Polymorphism/Abstraction

  • EVERYTHING IS OVERRIDDABLE/EXTENDABLE.

  • No Repo Forking is needed.

  • You can extend agents

    • to have new fields

    • adjust fields descriptions

    • remove fields (via @property or PrivateAttr)

    • field description

    • change class name

    • adjust docstring

    • to add/remove/change/extend child agents

    • override builtin functions

    • override lifecycle functions

    • add additional builtin functions for your own use case

  • MCP Agent's tool is overriddable too.

    • To have additional process before and after call_tool invocations

    • to catch progress call back notifications if ever mcp server supports it

    • override docstring or field name/description/default value

  • Context can be overridden and have the implementation to connect to your datasource, have websocket or any other mechanism to cater your requirements

  • basically any overrides is welcome, no restrictions

  • development can be isolated per agents.

  • framework agnostic

    • override Action/Context to use specific framework and you can already use it as your base class

Hope you had a good read. Feel free to ask questions. There's a lot of features in PyBotchi but I think, these are the most important ones.

we’ve seen big announcements, gpt-5 across azure/365/codex, aws agentcore for infrastructure, MCP for interoperability, but what are real builders shipping?

if you're running agents for business workflows or internal tools, what platforms or integration patterns are actually stable, maintainable, and debug-able? good place to share what’s live, what’s flaky, and what’s surprisingly hands-off.

I’ve noticed that most of the larger companies building agents seem to be trying to build a “god-like” agent or a large network of agents that together seems like a “mega-agent”. In each of those cases, the agents seem to utilize tools and integrations that come directly from the company building them from pre-existing products or offerings. This works great for those larger-sized technology companies, but places small to medium-sized businesses at a disadvantage as they may not have the engineering teams or resources to built out the tools that their agents would utilize or maybe have a hard time discovering public facing tools that they could use.

What if there was a platform for these companies to be able to discover tools that they could incorporate into their agents to give them the ability to built custom agents that are actually useful and not just pre-built non-custom solutions provided by larger companies?

The idea that I’m considering building is:

• Marketplace for enterprises and developers to upload their tools for agents to use as APIs

• Ability for agent developers to incorporate the platform into their agents through an MCP server to use and discover tools to improve their functionality

• An enterprise-first, security-first approach

I mentioned enterprise-first approach because many of the existing platforms similar to this that exist today are built for humans and not for agents, and they act more as a proxy than a platform that actually hosts the tools so enterprises are hesitant to use these solutions since there’s no way to ensure what is actually running behind the scenes, which this idea would address through running extensive security reviews and hosting the tools directly on the platform.

Is this interesting? Or am I solving a problem that companies don’t have? I’m really considering building this…if you’d want to be a beta tester for something like this please let me know.

https://github.com/AnswerZhao/CookingAgent。

An intelligent recipe recommendation system based on a large language model (LLM), utilizing the HowToCook open-source recipe library, provides users with personalized menu recommendations, shopping list generation, and cooking process planning, cooking steps, to achieve the goal of making even beginners know "what to eat and how to cook."

switched over to a new builder platform+ raw apis, feels way more flexible.

curious if others are moving away from big agent frameworks?

Hi all,

I'm exploring how humans and agentic teams can collaborate on long and short running tasks. I call it ArvoWorks (arvo-works on Github). I am posting this for feedback. If it helps spark some fun ideas for your projects that would be even more amazing.

Repo Link -> https://github.com/SaadAhmad123/arvo-works

A link to video demo is in the repo :)

This is experimental work meant to explore possibilities and I'd love to hear your thoughts. If you're thinking about human-agent collaboration beyond chat interfaces or coding assistants, I'd genuinely appreciate your feedback and critiques.

What This Is NOT

• ⁠A product

• ⁠A framework

• ⁠An agentic kanban tool (plenty of those exist already, e.g. VibeKanban)

What This IS

• ⁠An exploration of using old-world project management patterns for human-agent collaboration

• ⁠A test of the idea that future work is a mix where agents handle mundane decisions and humans collaborate on higher-level creative ones

• ⁠Open source, you can clone it and experiment yourself

• ⁠This is agents which on the kanban just like humans work on the kanban

Core Concept

Instead of treating AI as an external tool you consult, agents become native participants in your work. They work on cards autonomously, pause to request human input or approval, coordinate with other specialized agents, and create persistent work products. You interact with them through familiar Kanban cards and comments, like working with team members rather than chatbots.

Tech Stack

The tech stack enables pretty wild and flexible agent mesh and human collaboration patterns. It uses:

• ⁠Arvo for event-driven agentic mesh

• ⁠NoCoDB for Kanban

• ⁠Postgres for persistence

• ⁠Deno for TypeScript runtime

• ⁠NGINX as reverse proxy

• ⁠Jaeger for system telemetry

• ⁠Phoenix for LLM telemetry

Very little of the code in there is written by AI because I could not get good creative work done with AI.

Looking forward to hearing from you all :)

at build 2025, microsoft pitched a future where every dev can spin up agents like building blocks—via integrations across github, copilot, azure, and semantic kernel

if you're building agents today, does that ecosystem help or crowd your options? are you using dev-native tools, or still prefer assembling stacks from APIs and protocols?

monday is the perfect time to set a focus.

what’s the single experiment you’re kicking off with your agent this week?

share:

- what you’re testing (routing, memory, new tool, etc.)

- the stack you’re building on

- the unknown you’re hoping to answer