Reagent

Inspiration

Building an AI agent often means repeating the same setup: configuring models, connecting tools, writing prompts, defining guardrails, and setting up evaluations and monitoring. When teams need multiple agents, this work becomes redundant, inconsistent, and difficult to maintain.

We wanted to rethink how AI agents are built. Instead of treating every agent as an isolated application, we envisioned a platform where agents inherit shared configurations, policies, and resources from their organization and team.

Inspired by inheritance in software engineering, we built Reagent: a platform that makes AI agents reusable by separating what an agent does from what it is allowed to do. Developers can focus on defining an agent's purpose while Reagent handles the shared infrastructure, configuration, security, and evaluation needed to run it reliably.

What it does

Reagent is an enterprise AI agent platform that standardizes how agents are created, configured, tested, deployed, and monitored.

1. Inheritance-based agent configuration

Reagent organizes configurations into three layers: Enterprise, Team, and Agent. Enterprise administrators define organization-wide policies, available models, connectors, security requirements, and resource limits. Teams inherit these defaults while receiving their own permissions, shared resources, and team-specific rules. Individual agents inherit both layers and specify only what they need.

Inheritance follows a tighten-only principle: lower layers can restrict permissions and reduce limits, but they cannot override organizational policies to gain additional privileges. Changes to enterprise and team configurations automatically apply to agents on their next run, eliminating repetitive setup and keeping agents consistent.

2. Standardized .agent files

Every agent is defined using a versionable YAML-based .agent file. This creates a reusable, structured representation of an agent's behavior and configuration rather than scattering its setup across prompts, code, and dashboards.

An agent definition can specify:

Use case: Description, intended usage, and desired outcomes.
Model: Model selection, fallback model, temperature, and token limits.
Connectors and tools: Available integrations, permitted actions, resource scopes, and authentication modes.
Knowledge base and memory: Shared semantic knowledge, episodic run history, and procedural knowledge that can improve agent behavior after evaluation.
Evaluation: Test cases, quality thresholds, execution counts, and production sampling.
Triggers: HTTP requests, MCP, schedules, GitHub and Slack events, or calls from other agents.
Guardrails: Approval requirements, denied actions, and inherited security restrictions.
Budgets and limits: Per-run and monthly spending, maximum steps, timeouts, and concurrency.
Ownership: Agent owners and maintainers.
Observability: Metrics, alerts, execution traces, and failure notifications.
Failure handling: Retry policies, fallback behavior, and notifications.
Input and output schemas: Structured contracts that make agents easier to integrate and test.
Sub-agents: Other agents that can be invoked to delegate specialized tasks.

3. Shared memory and knowledge

Reagent supports shared memory at the enterprise and team levels, allowing agents to reuse organizational knowledge instead of repeatedly reconstructing context. Semantic memory stores facts and documentation, episodic memory records what happened during previous runs, and procedural memory captures proposed improvements to how agents work.

Memory access is governed by explicit read and write permissions. Procedural changes are applied only after the agent's evaluations pass again, helping prevent untested changes from silently altering behavior.

4. Automated evaluation and security

Reagent treats agents like software that must be tested before release. Its evaluator generates positive, negative, and safety test cases, including mocked tool interactions and expected outcomes.

Deterministic checks verify tool-call sequences, forbidden actions, side effects, output schemas, and information leaks. An LLM judge evaluates open-ended qualities that code cannot reliably assess. A security-reviewer agent identifies excessive permissions, risky actions, and opportunities to narrow an agent's configuration.

5. CI/CD for agents

Before publication, agents pass through validation, security review, test generation, human review, evaluation, and quality gates. Every new or changed test must be reviewed before evaluation and publication can proceed. Successful publication creates an immutable version with its evaluation report.

6. Monitoring and optimization

Reagent tracks execution histories, tool calls, errors, latency, spending, approval events, and evaluation results. Additional agents can diagnose failures, recommend configuration changes, and compare models and parameters to find lower-cost configurations that still satisfy quality requirements.

How we built it

We designed Reagent around a declarative configuration format and a layered resolution system.

Configuration system: YAML-based .agent, team, enterprise, connector, and model documents define agent behavior and reusable infrastructure.
Inheritance and policy resolution: A runtime merges enterprise, team, and agent configurations on every run, enforcing permission intersections, denylist unions, minimum resource limits, and inherited safety requirements.
Agent execution: A runtime coordinates model calls, connector actions, sub-agent invocations, triggers, budgets, retries, and human approvals.
Knowledge and memory: Shared memory buckets support semantic, episodic, and procedural information with access controls.
Evaluation framework: Agents are tested against structured cases using deterministic assertions and calibrated LLM judging where necessary.
Publishing workflow: A staged pipeline validates configurations, reviews security, generates and approves tests, executes evaluations, enforces quality thresholds, and publishes immutable versions.
Observability: Execution events, traces, costs, latency, and evaluation metrics provide visibility into agent behavior across development and production.

The architecture separates an agent's task-specific logic from the policies and resources it inherits. This allows teams to create new agents, fork existing ones, and reuse organizational infrastructure without duplicating every configuration.

Challenges we ran into

Designing inheritance without compromising security. Reuse is valuable only if agents cannot escape organizational restrictions. We designed a tighten-only resolution model in which permissions are intersected, denials accumulate, limits can only decrease, and stricter safety requirements cannot be disabled by lower layers.

Making agent evaluations trustworthy. AI outputs are inherently nondeterministic, so a single successful run does not establish reliability. We incorporated repeated test executions, confidence intervals, ground-truth benchmarks, deterministic assertions, and calibrated LLM judging to distinguish consistent performance from lucky results.

Balancing automation with human oversight. Automatically generated tests can contain mistakes or incorrect assumptions. Reagent requires human review of new or changed test cases before they can be used in the publishing pipeline.

Managing shared memory safely. Shared knowledge makes agents more reusable, but it can also introduce stale information or prompt-injection risks. We designed explicit access controls, redaction, source tracking, and evaluation-gated procedural memory updates.

Building a complete agent lifecycle. Creating an agent is only the beginning. Supporting versioning, forks, delegated agents, budget enforcement, failure recovery, publishing, and production monitoring requires coordination across multiple platform components.

Accomplishments that we're proud of

Making agent configurations reusable through inheritance: Enterprise, team, and agent layers reduce duplicated setup while preserving organizational control.
Creating a standardized .agent format: Agent behavior becomes structured, inspectable, portable, and versionable.
Treating evaluations as a publishing requirement: Agents cannot be published with unreviewed tests or without passing the required quality gates.
Combining deterministic testing with AI evaluation: Objective checks handle verifiable behavior, while an LLM judge assesses open-ended quality.
Building security into the architecture: Least-privilege permissions, resource scopes, approval requirements, and tighten-only inheritance help prevent unsafe configurations.
Supporting shared knowledge across agents: Enterprise and team memory allow agents to reuse context and organizational expertise.
Connecting development to production: Version history, execution traces, spending metrics, and failure analysis help teams understand and improve agents after deployment.

Our biggest accomplishment is approaching AI agents as reusable, governed software components rather than isolated prompts and tool integrations.

What we learned

We learned that building an AI agent is only one part of the problem. Making agents reusable, secure, testable, and maintainable across an organization requires a platform that manages the entire lifecycle.

Inheritance provides a powerful way to eliminate duplicated configuration, but it must be paired with explicit permission boundaries and predictable resolution rules. Shared memory can improve continuity across agents, but its contents and behavioral impact need governance. Evaluation is also more than checking whether an answer looks correct: it must account for tool usage, side effects, safety, consistency, latency, and cost.

Finally, automation works best when paired with accountability. Meta-agents can draft configurations, generate tests, identify risks, and recommend optimizations, while human review and enforced quality gates keep those recommendations from becoming uncontrolled production changes.

What's next for Reagent

We want to continue developing Reagent into a complete platform for building and managing enterprise AI agents.

Visual agent builder: Provide a node-based interface for inspecting and editing agent configurations, tools, connectors, memory, and sub-agent relationships.
Live inheritance visualization: Show which parameters come from enterprise, team, or agent layers, including their effective values and the source of each policy.
Richer shared knowledge: Expand knowledge-base ingestion, retrieval, source attribution, and controlled memory updates across teams and agents.
More comprehensive testing: Expand mutation testing, regression detection, judge calibration, and automated generation of adversarial and edge-case scenarios.
Smarter optimization: Automatically compare allowed models and parameter combinations to recommend the most cost-effective configuration that meets reliability requirements.
Deeper production observability: Improve trace exploration, cross-agent analytics, failure diagnosis, and alerts for cost or reliability regressions.
Stronger enterprise integrations: Expand connector support, approval workflows, identity controls, and deployment infrastructure.

Our long-term vision is to make creating an AI agent as straightforward as defining a software component: specify what it should accomplish, inherit the infrastructure and policies it needs, verify that it behaves correctly, and deploy it with confidence.