sharkasmAT A GLANCE
- Define agents, models, memory, tools, credentials, and triggers in YAML or through the visual Designer.
- Run agents with a LangGraph ReAct executor, with synchronous, asynchronous, and streamed responses.
- Connect agents to HTTP and SQL tools, Kafka, MCP servers, and other agents.
- Launch, stop, restart, and redeploy instances from the Orchestrator; inspect telemetry and operator conversations.
01 / 08
An agent platform with an operating model
PyBrain brings the pieces of an AI agent into a coherent platform: the agent definition, the model it uses, the tools it can call, the memory it can retain, and the triggers that start its work. Those relationships are declared in configuration and made visible in the Designer. The resulting agent is executed by a dedicated runtime and supervised through the Orchestrator. This gives the portfolio a concrete answer to a practical question: how do you move from an interesting agent conversation to a system people can configure, connect, run, and operate?
The work covers that complete path. Authoring is one responsibility, execution is another, and fleet supervision is a third. Keeping those responsibilities explicit makes the platform understandable to both the people building agents and the people responsible for their behavior once deployed.
02 / 08
Define behavior without hiding the structure
Agents, models, memory, tools, credentials, and triggers are defined in YAML. These definitions form the configuration the runtime loads. Resources are named and referenced, so the relationship between an agent and its tools can be inspected directly. A shared tool can be used by several agents without rewriting the same integration in each agent definition.
The visual Designer authors this same configuration. It presents models, tools, memory, credentials, and triggers as connected objects on a canvas. Schema-driven inspection and connection validation help authors understand what is attached to an agent. Import and export preserve a route between visual authoring and configuration review, allowing different team members to work with the representation that suits their role.
03 / 08
Execute through a consistent runtime
The runtime uses a LangGraph ReAct executor behind a FastAPI service. An invocation supplies a message and, where relevant, a session and contextual metadata. The runtime resolves the selected agent, model, tools, and memory, then executes the configured agent loop. The platform supports synchronous responses, asynchronous invocations, and streaming responses, which serve different application experiences.
An interactive conversation benefits from streamed output. A background task needs a durable way to identify and inspect its invocation. A straightforward integration may prefer a synchronous result. These are different ways to consume the platform while preserving the same underlying agent definition. The configuration remains the place where the agent’s connected resources are described.
04 / 08
Connect to the systems where work happens
PyBrain’s tool catalog spans HTTP services, SQL access, Kafka, MCP servers, agent-to-agent calls, and additional integration types. Tools connect the reasoning loop to information and actions outside the model. For a telecom use case, that can mean retrieving order information, looking up service inventory, or reading an operational record before producing a response.
Credential references sit alongside those tools without requiring secret values to be embedded in the agent’s configuration. The platform resolves credentials through supported providers at runtime. This distinction matters when the same integration is used across environments: the behavior can be reviewed as configuration while access is managed through the appropriate credential mechanism. Tool selection also makes the boundaries of an agent’s role explicit.
05 / 08
Make events a first-class entry point
Agent work can begin through a REST invocation, a configured HTTP webhook, or a Kafka trigger. The event-driven route is particularly relevant to operational systems because the interesting event often occurs outside a chat window. A consumer can receive a message, apply its configured filter, and invoke the relevant agent with context derived from that event.
Publishing is also available through agent tools. Integration outcomes can return to event streams, while platform telemetry uses separate streams for logs, execution output, traces, and audit information. Keeping these purposes distinct helps readers understand what a message represents: a business result, a piece of agent output, or evidence about the execution itself.
06 / 08
Operate a fleet, not just a prompt
The Orchestrator provides controls to launch, stop, restart, and redeploy live instances. It also offers telemetry and operator conversations. This makes deployment state and ongoing execution part of the product experience, rather than leaving them as an unrelated operational afterthought. The Designer and Orchestrator share a PostgreSQL-backed identity foundation, while the platform supports tenant-aware agent configuration and invocation.
For an operator, the central questions are concrete: which instance is running, what definition does it represent, what happened during an invocation, and what intervention is appropriate? The platform’s separation of design, runtime, and supervision provides a place for each question. It also makes room for controlled revisions as agents and integrations evolve.
07 / 08
A telecom example: provisioning fallout
The documented provisioning-fallout template demonstrates how PyBrain can organize a cross-system investigation. It begins with the order and its provisioning events, moves to service inventory and catalog context, then checks the relevant DOCSIS or FTTH provisioning state and customer-premises equipment. The template’s HTTP endpoints are configurable, so the connections are wired to the environment in which it is used.
The example is useful because the answer rarely lives in one system. An order can exist while an equipment assignment is wrong, or a device can be present while the expected service has not become active. The workflow brings these observations together into findings and a recommended next step.
08 / 08
Understand how the agent reached its result
PyBrain’s observability includes structured logs, Prometheus metrics, OpenTelemetry instrumentation, audit events, and optional LangSmith and Kafka integrations. Request identifiers connect an invocation to its surrounding operational evidence. LLM and tool-call visibility is handled through the documented LangSmith or Kafka tracing integrations, alongside service-level telemetry.
This is important when an answer needs investigation. The operator should be able to distinguish a slow external tool, a failed request, an unsuitable input, and a reasoning path that needs refinement. The purpose of these signals is to support that examination. PyBrain’s place in the wider portfolio is therefore both practical and architectural: it connects models to operational tools while providing a platform for designing, supervising, and inspecting the work they perform.
LET’S MAKE THE CONNECTION
Put this experience
to work.
Bring your requirements, your operating context, and the question you want to answer.
Discuss PyBrain ↗