Orgentics

Orgentics is my attempt to build a small framework for multi-agent orchestration on top of Semantic Kernel.

The idea is to experiment with how agents can cooperate in a simulated enterprise-like environment, focusing on zero-trust and least-privilege principles while exploring the concept of Organization-as-a-Service.

Agents run as segregated, stateless and scalable worker threads, communicating asynchronously with each other via a ticketing system (resembling GitHub issues) in a constrained way, and using plugins/tools under configurable permissions.

The main feature is the ability to define an organization of agents by simply writing a markdown specification, which defines the agents' prompts, their parameters, roles and permissions - like allowed plugins and interactions.

It is currently not intended as a production framework, but just as a toy project for experimentation, replicating ideas that may already exist in other well-known SOTA frameworks.

Core Concepts

• Organization-as-a-Service: we want to define entire organizations composed of agents (teams, business units, or something bigger) simply by writing a specification, then make organizations runnable and use it as a commodity.

• Configuration-as-Code: organizations should be created by configuration, without coding. A markdown file defines the global mission, each role's responsibilities and constraints, and other parameters for fine-tuning the agents' behavior.

• Zero-trust and least-privilege: the security policies defined in the configuration are enforced at runtime. Agents can only interact in a controlled way, and use plugins accordingly to their role inside the organization.

• Scalability: agents are stateless and asynchronous actors, they can be scaled horizontally at need. The runtime shall handle load balancing automatically.

See organization.md for an example of specification.

Communication Model

Agents communicate asynchronously using a lightweight ticketing system, just like human employees would do inside a real company. Tickets allow agents to:

• Request help from other agents,
• Delegate or hand over work,
• Reply or provide status updates, if explicitly permitted (not all agents are allowed to talk directly to the user).

Plugins and Tools

Agents can use plugins/tools, but plugin access is constrained by permissions. Current capabilities include:

• Working memory (private, shared per-role or global),
• Ticket management (create, answer, assign, close),
• Discovering other agents and their roles/capabilities,
• Basic console-based interaction with the user.

Next Steps

• Implementing a scheduling plugin, allowing agents to plan and schedule tasks over time,
• Implement agent autoscaling, eg. spawn new agent instances when ticket queue is long,
• Support for MCP and other IO mechanisms: email, webhooks, FTP, and so on,
• Support for other LLM providers different from (Azure)OpenAI,
• Experiment with inter-organization communication (eg. modeling complex supply chain scenarios) using industry standards for secure communication, like mutual authentication, JWT tokens, etc.