Pulse Mesh

• Curated agent templates (marketing, interviews, etc)
• Each template has some workflow (toolsets, problem to solve, etc)
• NOT an agent framework, but a product that creates agents, kinda an "internal framework"
• Some agents/workflows get data, others actuate on it, others both. Some are final-user facing, others are client facing.

Agent factory

Receives a petition with an agent kind (template):

• Creates the container injecting API keys (user and admin), template files, env_vars, etc

The agent template:

• Configuration files:
  • system.md (curated "modules" or "experts", eg. marketing, interview, etc)
  • instructions.md (user facing for further customization)
  • soul.md (personality, tone, etc.)
• Programatic configuration:
  • environment ("Hard variables": organization_id, agent name, company name, etc.)
  • available tools / toolset(s)

The client company's context is also inserted. Eg: Cocacola, we make and sell soda. etc. As a client_context.md.

Architecture

[ database ]
[ data access layer ]
[ tools ] - [ toolsets ]
[ api rest ] - [ mcp ] - [ agents ]

The database would be normalized and standarized, with composable access points.

These access points would be akin to java repositories, but in python, rust, or whatever, like an orm with a thin layer on top (validation, etc).

The tools would act as a bridge between the MCP and the access points, and toolsets would encompass different tools: shared ones, special ones, etc.

Finally the API REST would interact with the data access points directly, with authentication, for non-agentic consumption. The MCP would register tools and toolsets and serve them to agents. And agents would interact with the system with specific tools(ets) depending on their template (eg. a marketing agent wouldnt need the interview agent's toolset).

Pulse Node

Each Pulse Mesh Agent is a Pulse Node. Basically an agent running inside an application in a container.

The agent connects to our MCP, and depending on its template, have specific workflows enabled via toolsets. Some things might be immutable (eg. config like the org_id, etc), but others like the SOUL.md and instructions.md could be modified by the client via a web interface.

These agents are ephimeral: The node itself is long-running, but, to not saturate the context and refresh configurations (eg changes in soul.md, etc), the agents are created, perform their thing, and die, with the node creating as many as needed, when needed.

Notes

• Does the instructions.md go into the system prompt? or instructions field? What about the soul.md?

Tech stack

• Pydantic AI
• Pydantic Logfire (observability)