Skip to main content

Building Genesis: An AI Agent Meta-Factory

By Upendra

Building Genesis: An AI Agent Meta-Factory

For months, I've been exploring OpenClaw and intelligent agent systems. Today, I'm sharing how I built Genesis—a meta-agent that creates other agents with automatically-generated guardrails.

The problem Genesis solves is simple: creating specialized agents is tedious, repetitive, and error-prone. Genesis automates that entire process.

The Problem: Agent Creation Is Hard

Traditionally, creating a new agent requires:

  • Manual specification: What guardrails does this agent need?
  • Risk assessment: What could go wrong?
  • Permission management: Who approves this?
  • Complexity: Different agents need different constraints
  • Tracking: What agents exist? What can they do?
  • Consistency: Are guardrails applied uniformly?

This is slow, inconsistent, and doesn't scale.

The Solution: Genesis

Genesis is a meta-agent—an agent that creates agents. It works like this:

User Request
    ↓
Genesis Analyzes ("What kind of agent do you need?")
    ↓
Genesis Determines Category (utility, analysis, automation, integration, critical)
    ↓
Genesis Generates Guardrails (automatically, based on type and risk)
    ↓
Genesis Requests Approval (if needed)
    ↓
Genesis Creates Agent (with proper constraints)
    ↓
Agent Added to Registry (tracked and managed)

How Genesis Works

1. Request Analysis

When you ask Genesis to create an agent, it understands:

  • Intent: What is this agent supposed to do?
  • Capabilities needed: What will it access? Files? APIs? Data?
  • Risks: What could go wrong?
  • Category: Utility? Analysis? Automation? Integration? Critical?
You: "Genesis, create a code reviewer agent"

Genesis thinks:
├─ Intent: Review code for quality
├─ Capabilities: Read code files, analyze
├─ Risk: Low (read-only, no external APIs)
├─ Category: Analysis
└─ Auto-create? YES

2. Intelligent Guardrail Generation

Genesis doesn't ask you to write guardrails. It generates them automatically based on:

  • Agent type (analysis agents get balanced guardrails)
  • Required capabilities (API access = stricter guardrails)
  • Data sensitivity (sensitive data = locked guardrails)
  • Risk level (high risk = approval required)

3. Permission Workflow

If guardrails are appropriate, Genesis auto-creates. If risky, it asks for approval:

Genesis shows:
┌─────────────────────────────────┐
│ CODE REVIEWER AGENT             │
├─────────────────────────────────┤
│ Can do:                         │
│ ✓ Read code files              │
│ ✓ Analyze for issues           │
│ ✓ Generate reports             │
│ ✗ Delete files (DENIED)        │
├─────────────────────────────────┤
│ Guardrails:                     │
│ • Read-only access             │
│ • No external APIs             │
│ • 5-minute timeout             │
│ • Logging enabled              │
├─────────────────────────────────┤
│ [APPROVE] [DENY] [MODIFY]      │
└─────────────────────────────────┘

You: APPROVE

Genesis: ✅ Code Reviewer created!

4. Agent Created with Guardrails

The agent is created with all constraints baked in:

You: code-reviewer-001: Review my Python file

Agent: [Analyzes code]
✓ Style issues found
✓ Performance suggestions
✓ Best practices noted
→ Report generated

[No file modifications, no API calls, staying within constraints]

The 5 Agent Types Genesis Creates

Genesis categorizes agents into 5 types:

🟢 Utility (Auto-Create)

  • File operations, calculations, text processing
  • Low risk, minimal guardrails
  • Example: "Batch rename files"

🟡 Analysis (Auto-Create)

  • Research, data analysis, code review
  • Medium risk, balanced guardrails
  • Example: "Analyze sales trends"

🟠 Automation (Needs Approval)

  • Workflows, scheduled tasks
  • Medium-high risk, balanced guardrails
  • Example: "Daily email summary"

🔶 Integration (Needs Approval)

  • External APIs, service connections
  • High risk, strict guardrails
  • Example: "Sync Salesforce to CRM"

🔴 Critical (Always Needs Approval)

  • Admin, deletions, system changes
  • Very high risk, locked guardrails
  • Example: "Archive old files"

Smart Guardrail Generation Rules

Genesis uses intelligent rules:

  1. Start with category-based guardrails

    • Utility → Minimal
    • Analysis → Balanced
    • Integration → Strict

  2. Escalate based on risky operations

    • External APIs → Add strict rate limiting
    • File modifications → Add approval gates
    • Sensitive data → Add logging

  3. Add monitoring and limits

    • All agents get rate limits
    • All agents get timeouts
    • Critical operations get logging

  4. Deny dangerous operations by default

    • Can't create agents without Genesis
    • Can't bypass guardrails
    • Can't access other agents' memory

Real Example: Creating a Salesforce Integration

You: "Genesis, create a Salesforce integration agent"

Genesis analyzes:
├─ Type: Integration (high risk - external API)
├─ Auto-create? NO (needs approval)
├─ Guardrail level: STRICT
└─ Show approval request

Genesis shows you:
┌──────────────────────────────────────────┐
│ SALESFORCE INTEGRATION AGENT             │
├──────────────────────────────────────────┤
│ Capabilities:                            │
│ ✓ Read Salesforce leads                 │
│ ✓ Create/update leads                   │
│ ✗ Delete leads (DENIED)                 │
│ ✗ Access user accounts (DENIED)         │
├──────────────────────────────────────────┤
│ Guardrails (why each matters):           │
│ • API key encrypted: Credential security │
│ • Rate limit 100/min: Quota protection   │
│ • All calls logged: Audit trail          │
│ • Timeout 10 min: Resource protection    │
│ • Read-mostly: Prevents accidental mods  │
├──────────────────────────────────────────┤
│ [APPROVE] [DENY] [MODIFY]               │
└──────────────────────────────────────────┘

You: APPROVE

Genesis: ✅ Salesforce Agent created!
Guardrails: Strict | Status: Active

Key Insights

1. Guardrails Should Enable, Not Restrict

The best guardrails are like good laws—they prevent harm while enabling good behavior.

Bad guardrail: "Agent can never access external data"
Good guardrail: "Agent can access external APIs with pre-approval and rate limiting"

2. Approval Workflows Matter

Not all agents need approval. Knowing when to ask is crucial:

  • Utility agents? Auto-create.
  • Salesforce access? Ask for approval.
  • File deletion? Always ask.

3. Tracking Is Essential

Every agent should be registered, with metadata about:

  • What it can do
  • What it cannot do
  • When it was created
  • Who created it
  • What guardrails it has

4. Configuration-Driven Is Better Than Hard-Coded

Instead of baking rules into code:

# Bad: Hard-coded rules
if agent_type == "integration":
    rate_limit = 100
    timeout = 300
    log_all = True

# Good: Configuration-driven
guardrails = load_template(agent_type, risk_level)
apply_guardrails(agent, guardrails)

This way, you can evolve guardrails without changing code.

The Architecture

Genesis uses OpenClaw's capabilities:

  • sessions_spawn: For creating sub-agents
  • JSON registries: For tracking agents
  • Configuration files: For guardrail definitions
  • System prompts: For agent behavior
genesis-config.json
    ↓
    [Auto-create settings, approval rules, max agents]
    
guardrail-templates.json
    ↓
    [Guardrail definitions for each agent type]
    
agent-registry.json
    ↓
    [Central registry of all created agents]
    
genesis-prompt.md
    ↓
    [Genesis's system prompt - how it thinks]

What Genesis Enables

With Genesis, you can:

✅ Create specialized agents in seconds
✅ Stop worrying about guardrails (Genesis handles them)
✅ Request approval for risky operations
✅ Track all agents in one place
✅ Modify guardrails safely
✅ Scale agent creation without sacrificing safety

The Future

Genesis is just the beginning. Next steps:

  • 🚀 Self-improving guardrails: Learn from agent behavior
  • 🔄 Agent migration: Move agents between guardrail levels
  • 📊 Analytics: Understand which agents are useful
  • 🤝 Agent collaboration: Agents working together
  • 🧠 Context preservation: Agents learning from each other

Lessons Learned

  1. Automation should be smart: Don't just replace human decision-making with dumb rules
  2. Safety is a feature: Good guardrails enable capability, not restrict it
  3. Tracking matters: You need to know what agents exist and what they can do
  4. Configuration beats code: Make your system configurable, not hard-coded
  5. Approval workflows save lives: Know when to ask before acting

Conclusion

Genesis represents a shift in how we think about agent creation:

  • From manual: Hand-write every guardrail

  • To intelligent: Genesis figures out what's appropriate

  • From inconsistent: Different rules for different agents

  • To systematic: Standardized, configuration-driven approach

  • From risky: Over-restrict or under-protect

  • To balanced: Right level of guardrails for each agent type

It's a small step toward a future where AI agents are smarter, safer, and easier to create.

Try Genesis Now

"Genesis, come online"
"Genesis, create a utility agent for file organization"
"Genesis, show all agents"

Check out the Genesis documentation to learn more.

What agents would you create with Genesis? Share your ideas in the comments! Let's build the future of intelligent agents together.

Published on upendrasengar.com
Also available on Dev.to
Code examples on GitHub

Labels:

Comments

Post a Comment

Popular posts from this blog

AngularJs call one method of controller in another controller .

By Upendra
I have seen many question about calling one method of one controller in another controller or extending scope of one controller in another controller.so here are the ways. if you want to call one controller into another or extending scope of controllers there are four methods available $rootScope.$emit() and $rootScope.$broadcast() If Second controller is child ,you can use Parent child communication . Use Services Kind of hack - with the help of angular.element() 1. $rootScope.$emit() and $rootScope.$broadcast() Controller and its scope can get destroyed, but the $rootScope remains across the application, that's why we are taking $rootScope because $rootScope is parent of all scopes . If you are performing communication from parent to child and even child wants to communicate with its siblings, you can use $broadcast If you are performing communication from child to parent ,no siblings invovled then you can use $rootScope.$emit HTML <body ng-app = ...
7 comments
Read more

Closures in javascript and how do they work ?

By Upendra
JavaScript Closures for Dummies  Closures Are Not Magic This page explains closures so that a programmer can understand them — using working JavaScript code. It is not for gurus or functional programmers. Closures are  not hard  to understand once the core concept is grokked. However, they are impossible to understand by reading any academic papers or academically oriented information about them! This article is intended for programmers with some programming experience in a mainstream language, and who can read the following JavaScript function: function sayHello ( name ) { var text = 'Hello ' + name ; var sayAlert = function () { alert ( text ); } sayAlert (); } An Example of a Closure Two one sentence summaries: a closure is the local variables for a function — kept alive  after  the function has returned, or a closure is a stack-frame which is  not deallocated  when the function returns (as if a 'stack-fr...
Post a Comment
Read more

Working with $scope.$emit , $scope.$broadcast and $scope.$on

By Upendra
First of all, parent-child scope relation does matter. You have two possibilities to emit some event: $broadcast  -- dispatches the event downwards to all child scopes, $emit  -- dispatches the event upwards through the scope hierarchy. If scope of  firstCtrl  is parent of the  secondCtrl  scope, your code should work by replacing  $emit  by  $broadcast  in  firstCtrl : function firstCtrl ( $scope ) { $scope . $broadcast ( 'someEvent' , [ 1 , 2 , 3 ]); } function secondCtrl ( $scope ) { $scope . $on ( 'someEvent' , function ( event , mass ) { console . log ( mass ); }); } In case there is no parent-child relation between your scopes you can inject  $rootScope  into the controller and broadcast the event to all child scopes (i.e. also  secondCtrl ). function firstCtrl ( $rootScope ) { $rootScope . $broadcast ( 'someEvent' , [ 1 , 2 , 3 ]); } Finally, when you need to ...
Post a Comment
Read more