Command-less AI Architecture: Goal-Driven Agents That Generate Their Own Tools Without Pre-Defined Commands

1. The Command Paradigm Problem

Every major agent framework today — LangChain, AutoGPT, CrewAI, Microsoft Autogen — operates on the same fundamental assumption: agents act by selecting from a pre-defined set of commands (tools, functions, APIs). The agent's capability is bounded by its command registry. If the registry contains 50 tools, the agent can do 50 things. If a task requires a 51st capability, the agent fails or hallucinates a workaround.

This design choice is a direct inheritance from traditional software architecture, where programs are composed of function calls against known interfaces. It works well for deterministic, predictable workloads. It fails catastrophically for the kinds of open-ended, adaptive tasks that enterprises actually need agents to perform.

1.1 Brittleness Under Novel Requirements

Consider a planning agent tasked with optimizing supply chain logistics. Its command registry includes tools for route calculation, inventory queries, and cost estimation. A new requirement emerges: the agent must factor in carbon emissions per route. The command-bound agent has no carbon calculation tool. It cannot proceed. An engineer must implement the tool, register it, test it, and redeploy. The latency between requirement and capability is measured in days or weeks.

This is not an edge case — it is the normal operating condition for enterprise AI. Business requirements evolve continuously. Regulatory environments shift. Market conditions change. An agent architecture that requires human engineering effort for every new capability is an architecture that cannot keep pace with the business it serves.

1.2 The Combinatorial Explosion of Commands

Even if we could anticipate every required capability, the command registry approach faces a combinatorial problem. Real-world tasks require not just individual tools but compositions of tools in specific sequences with conditional branching. A registry of N tools implies O(N!) possible execution orderings. Pre-defining all valid compositions is intractable. Agents must discover compositions at runtime — but if they can discover compositions, why can they not discover the tools themselves?

The insight at the heart of command-less architecture: if agents are already planning how to compose tools, they should also be able to plan how to create tools. Planning and tool generation are the same cognitive operation applied at different abstraction levels.

2. Goal-Driven Architecture

The command-less architecture replaces the command-execution loop with a goal-plan-execute loop. The fundamental unit of work is not the command but the goal. A goal is a declarative specification of a desired end state, with optional constraints, quality criteria, and accountability metadata.

The architecture operates in four phases:

Phase 1 — Goal Reception. The agent receives a goal G from a human principal, another agent, or a governance trigger. The goal includes a natural language description, formal success criteria where available, constraint boundaries, and a responsibility assignment (which MARIA coordinate bears accountability).

Phase 2 — Decomposition. The agent decomposes G into a directed acyclic graph (DAG) of sub-goals {g_1, g_2, ..., g_m}, where edges represent dependencies. Each sub-goal inherits the constraint boundaries of its parent but may have additional constraints derived from the decomposition process.

Phase 3 — Capability Matching. For each leaf-level sub-goal g_i, the agent queries its capability model C to determine whether it possesses the tools necessary to achieve g_i. If a gap is detected (required capabilities exceed available capabilities), the agent enters the tool synthesis phase.

Phase 4 — Execution. The agent executes the plan, traversing the DAG in topological order, monitoring execution against success criteria, and adapting the plan if execution results deviate from expectations.

G \xrightarrow{\text{decompose}} \text{DAG}(g_1, g_2, \ldots, g_m) \xrightarrow{\text{match}} \Delta C \xrightarrow{\text{synthesize}} T' \xrightarrow{\text{execute}} R

The critical departure from command-driven architecture occurs between Phase 3 and Phase 4: when the agent discovers it lacks a required capability, it does not fail or escalate — it generates the capability. This is the self-extending property that distinguishes command-less agents from all prior architectures.

3. Plan Generation: Hierarchical Task Decomposition

Plan generation is the process of transforming a goal into an executable strategy. In the command-less architecture, plans are first-class objects with formal structure, version history, and governance metadata.

3.1 Plan Structure

A plan P is a tuple (N, E, pre, post, inv) where N is a set of task nodes, E is a set of dependency edges, pre is a precondition function mapping each node to its required state, post is a postcondition function mapping each node to its expected output state, and inv is an invariant function defining properties that must hold throughout execution.

interface Plan {
  id: string
  goalId: string
  nodes: TaskNode[]
  edges: DependencyEdge[]
  preconditions: Map<string, Condition>
  postconditions: Map<string, Condition>
  invariants: Condition[]
  version: number
  generatedBy: MARIACoordinate
  auditTrail: PlanDecisionLog[]
}

interface TaskNode {
  id: string
  description: string
  requiredCapabilities: Capability[]
  estimatedCost: ResourceEstimate
  rollbackStrategy: RollbackPlan | null
  status: 'pending' | 'active' | 'completed' | 'failed' | 'rolled_back'
}

interface DependencyEdge {
  from: string  // TaskNode id
  to: string    // TaskNode id
  type: 'hard' | 'soft'  // hard = must complete; soft = preferred
  dataFlow?: DataContract   // schema of data passed between nodes
}

3.2 Dependency Graph Construction

The decomposition algorithm constructs the dependency graph through iterative refinement. Starting from the root goal, each sub-goal is analyzed for dependencies on other sub-goals. Dependencies are classified as hard (must complete before successor begins) or soft (preferred ordering but not strictly required). The algorithm terminates when all leaf nodes map to known capabilities or to capability gaps that trigger tool synthesis.

The depth of the plan tree is bounded logarithmically in the complexity of the goal. We define goal complexity |G| as the number of distinct capability types required for completion. The decomposition algorithm, by halving the capability scope at each level, produces a tree of depth O(log |G|). This ensures that even compound goals with dozens of required capabilities yield manageable plan structures.

\text{depth}(P) \leq \lceil \log_2 |G| \rceil + 1

3.3 Plan Validation

Before execution, every generated plan passes through a validation gate. The validator checks three properties: (1) completeness — every required capability is covered by at least one task node; (2) consistency — no two task nodes produce contradictory postconditions; (3) feasibility — resource estimates do not exceed allocated budgets. Plans that fail validation are returned to the decomposition phase with diagnostic information, enabling iterative refinement.

4. Dynamic Tool Generation

When plan generation identifies a capability gap — a task node whose required capabilities are not present in the agent's tool inventory — the agent enters the tool synthesis protocol. This is the most radical element of the command-less architecture: the agent creates the tools it needs.

4.1 Synthesis Protocol

Tool synthesis follows a four-step protocol. First, the agent formalizes the specification of the missing tool: its input schema, output schema, behavioral contract (what the tool must do), and constraint boundaries (what the tool must not do). Second, the agent searches its knowledge base for analogous tools — existing tools that share partial input/output signatures or behavioral properties. Third, the agent generates a candidate implementation, either by composing existing tools, adapting an analogous tool, or generating code from specification. Fourth, the candidate undergoes automated testing against the behavioral contract, with failing candidates rejected and regenerated.

interface ToolSynthesisRequest {
  requiredBy: TaskNode
  inputSchema: JSONSchema
  outputSchema: JSONSchema
  behavioralContract: {
    description: string
    testCases: TestCase[]
    constraints: string[]
  }
  analogousTools: Tool[]
  maxSynthesisAttempts: number
  governanceGate: GateConfig  // requires approval if risk > threshold
}

async function synthesizeTool(req: ToolSynthesisRequest): Promise<Tool> {
  for (let attempt = 0; attempt < req.maxSynthesisAttempts; attempt++) {
    const candidate = await generateCandidate(req)
    const testResults = await runBehavioralTests(candidate, req.behavioralContract)
    if (testResults.allPassed) {
      await registerTool(candidate, req.requiredBy)
      await logSynthesisDecision(candidate, req, testResults)
      return candidate
    }
    await logFailedAttempt(candidate, testResults, attempt)
  }
  throw new SynthesisFailure(req)  // escalate to human
}

4.2 Governance Controls on Synthesis

Unrestricted tool generation is dangerous. An agent that can create any tool can create tools that violate security policies, access unauthorized data, or perform irreversible actions. The command-less architecture addresses this through layered governance controls.

Every synthesized tool is assigned a risk score based on its capabilities: tools that read data are low risk; tools that write data are medium risk; tools that interact with external systems or perform financial transactions are high risk. High-risk tools require human approval before registration. All synthesized tools, regardless of risk level, are logged with their full specification, generation rationale, test results, and the MARIA coordinate of the agent that created them.

Tool synthesis without governance is capability generation without accountability. Every synthesized tool must pass through a Fail-Closed Gate that defaults to human review when risk cannot be assessed. The principle: more synthesis freedom requires more governance infrastructure.

5. Execution Engine: Plan Execution with Adaptation

The execution engine traverses the plan DAG in topological order, executing each task node with its assigned tool, collecting results, and feeding outputs to dependent nodes via the data contracts defined in dependency edges.

5.1 Rollback and Retry

When a task node fails, the execution engine consults the node's rollback strategy. If the failure is transient (network timeout, rate limit), the engine retries with exponential backoff. If the failure is structural (incorrect tool behavior, invalid assumption), the engine rolls back completed dependent nodes and returns the sub-plan to the decomposition phase for replanning. Rollback is bounded: each node specifies a maximum rollback depth to prevent cascading undo operations.

5.2 Adaptive Replanning

The execution engine monitors invariants throughout plan execution. When an invariant is violated — for example, accumulated cost exceeds budget, or an intermediate result deviates from expected ranges — the engine pauses execution and triggers adaptive replanning. The replanning phase receives the current execution state, the violated invariant, and the remaining plan, and produces a revised plan that accounts for the new information. This enables the agent to adapt to runtime surprises without human intervention, provided the adaptation falls within the agent's autonomy boundaries.

6. Mathematical Framework

We formalize the command-less architecture through three mathematical spaces and the morphisms between them.

6.1 Goal Space G

The Goal space G is a partially ordered set (poset) where the ordering relation represents goal subsumption: g_1 ≤ g_2 if achieving g_2 implies achieving g_1. Goals have a complexity measure |g| defined as the minimum number of distinct capability types required for completion.

(G, \leq) \text{ where } g_1 \leq g_2 \iff \text{achieving } g_2 \text{ implies achieving } g_1

6.2 Plan Space P

The Plan space P is the set of all valid DAGs over task nodes. A plan p is valid if and only if it is acyclic, all leaf nodes map to capabilities in the current tool space or to synthesis requests, and all precondition-postcondition chains are consistent.

P = \{ p = (N, E) \mid \text{acyclic}(p) \wedge \forall n \in \text{leaves}(p): \text{cap}(n) \subseteq C \cup S \}

6.3 Tool Space T

The Tool space T is a set equipped with a composition operation. Two tools t_1, t_2 can be composed (t_1 ; t_2) if the output schema of t_1 is compatible with the input schema of t_2. The initial tool space T_0 is the agent's pre-loaded tool inventory. At each planning cycle, tool synthesis may add new elements to T, yielding T_{k+1} = T_k ∪ synth(k).

T_{k+1} = T_k \cup \text{synth}(\Delta C_k), \quad |\text{synth}(\Delta C_k)| \leq |\Delta C_k|

6.4 Morphisms

The decomposition function δ: G → P maps goals to plans. The capability matching function μ: P → 2^C maps plans to required capability sets. The synthesis function σ: 2^C \ C → T maps capability gaps to new tools. The composition δ then μ then σ defines the full goal-to-tool pipeline.

\delta: G \to P, \quad \mu: P \to 2^C, \quad \sigma: 2^C \setminus C \to T

The key theorem is that these morphisms are composable and that their composition preserves the governance invariants: every tool in the image of σ ∘ μ ∘ δ carries a full provenance chain back to the originating goal.

7. Command-less OS Design in MARIA OS

MARIA OS implements the command-less architecture through three architectural decisions that replace the traditional command registry.

7.1 Capability Graphs Replace Command Registries

Instead of a flat list of registered commands, MARIA OS maintains a capability graph — a directed graph where nodes are capabilities and edges represent composition relationships, similarity relationships, and derivation relationships. When an agent needs a capability, it queries the graph for the closest match, not an exact command name. This enables fuzzy matching: an agent that needs 'carbon emission calculation' might find 'energy cost estimation' as a nearby capability and adapt it.

7.2 Goal Contracts Replace API Specifications

In traditional architectures, inter-agent communication is mediated by API specifications — fixed schemas that both sender and receiver must conform to. In MARIA OS, agents communicate through goal contracts: declarative statements of what the sender needs the receiver to achieve, with success criteria. The receiver is free to achieve the goal through any means available, including synthesizing new tools.

7.3 Evidence-Based Tool Promotion

Dynamically synthesized tools start in a 'provisional' state with restricted usage. As a tool accumulates evidence of correct behavior — successful executions, passed tests, governance reviews — it is promoted through maturity levels: provisional → validated → trusted → core. Core tools are indistinguishable from pre-loaded tools. This allows the tool space to grow organically while maintaining quality standards.

type ToolMaturity = 'provisional' | 'validated' | 'trusted' | 'core'

interface ToolPromotionCriteria {
  provisional_to_validated: {
    minSuccessfulExecutions: 10
    minDistinctContexts: 3
    maxFailureRate: 0.05
  }
  validated_to_trusted: {
    minSuccessfulExecutions: 100
    humanReviewPassed: true
    securityAuditPassed: true
  }
  trusted_to_core: {
    minSuccessfulExecutions: 1000
    minAge: '30d'
    governanceBoardApproval: true
  }
}

8. Comparison: Command-Based vs. Goal-Based Agents

| Dimension | Command-Based Agent | Goal-Based Agent (MARIA OS) |
|---|---|---|
| Capability Boundary | Fixed at deployment | Expands at runtime |
| Novel Task Handling | Fails or hallucinates | Decomposes, synthesizes, executes |
| Adaptation Latency | Days (requires engineering) | Minutes (autonomous synthesis) |
| Composition Discovery | Pre-defined workflows | Runtime plan generation |
| Audit Trail | Command execution logs | Goal → Plan → Tool → Execution traces |
| Governance Model | Permission per command | Risk-scored synthesis gates |
| Scalability | Linear in command count | Logarithmic in goal complexity |
| Inter-Agent Communication | API calls | Goal contracts |
| Failure Mode | Silent inability | Explicit gap detection + escalation |
| Tool Ecosystem Growth | Manual addition | Organic + evidence-based promotion |

9. Recursive Planning: Plans That Generate Plans That Generate Tools

The most powerful property of the command-less architecture is recursive planning. A plan can include task nodes whose objective is to generate sub-plans. A sub-plan can include task nodes whose objective is to synthesize tools. This creates a three-level recursion — goal to plan to sub-plan to tool — that enables emergent problem-solving capabilities impossible in command-bound architectures.

9.1 Emergence Through Recursion

Consider a strategic planning agent tasked with entering a new market. The top-level plan decomposes into market analysis, competitive assessment, regulatory review, and go-to-market strategy. The market analysis sub-goal generates its own plan, which discovers it needs a tool for analyzing social media sentiment in the target market's language. The agent synthesizes a sentiment analysis tool adapted to the specific linguistic context. This tool was not in the original registry. No engineer anticipated the need. The agent's recursive planning capability created an emergent competence.

\text{RecPlan}(G) = \delta(G) \cup \bigcup_{g_i \in \text{leaves}(\delta(G))} \text{RecPlan}(g_i)

9.2 Recursion Bounds

Unbounded recursion is as dangerous as unbounded tool generation. The architecture enforces recursion depth limits at two levels: the plan decomposition depth (maximum DAG depth before a task must be directly executable) and the synthesis depth (maximum number of tool-synthesis-within-tool-synthesis chains). Default limits are 5 for plan decomposition and 2 for synthesis depth. These limits can be adjusted per agent based on its trust level and governance tier.

10. Evidence Trail: Governance in a Command-less World

A common objection to command-less architecture is that it is ungovernable: if agents can generate arbitrary tools, how do we audit what they do? The MARIA OS answer is that command-less architecture is actually more governable than command-based architecture, because every tool carries its full provenance.

In a command-based architecture, the audit trail is: 'Agent X executed command Y with parameters Z.' This tells you what happened but not why. In a command-less architecture, the audit trail is: 'Agent X received goal G, decomposed it into plan P, detected capability gap ΔC, synthesized tool T to fill the gap, tested T against behavioral contract B, and executed T within plan P.' This tells you what, why, how, and with what governance controls.

interface CommandlessAuditRecord {
  goalId: string
  goalDescription: string
  planId: string
  planVersion: number
  taskNodeId: string
  capabilityGap: Capability[] | null
  synthesizedTool: {
    toolId: string
    specification: ToolSpec
    testResults: TestResult[]
    riskScore: number
    approvalStatus: 'auto' | 'human_approved'
  } | null
  executionResult: {
    status: 'success' | 'failure' | 'rolled_back'
    outputs: Record<string, unknown>
    duration: number
    resourcesConsumed: ResourceMetrics
  }
  responsibleCoordinate: string  // MARIA coordinate
  timestamp: string
}

Every audit record links back to the originating goal, creating an unbroken chain from business intent to technical execution. This chain is the foundation of accountability in a command-less system: responsibility flows from goal to plan to tool to execution, and at every link, a MARIA coordinate identifies who authorized the transition.

11. Convergence: Goal-Driven Agents Stabilize Their Tool Space

A natural concern with dynamic tool generation is runaway growth: will the tool space expand without bound? We prove that under reasonable assumptions, the tool space converges.

Theorem (Tool Space Convergence). Let G be a bounded goal domain with finite capability requirements |C_req|. Let T_k be the tool space after k planning cycles. Then there exists K such that for all k > K, |T_{k+1} \ T_k| = 0. That is, the tool space stabilizes.

\text{Let } C_{\text{req}} = \bigcup_{g \in G} \text{required}(g). \text{ Since } |C_{\text{req}}| < \infty \text{ and each synthesis adds at least one element of } C_{\text{req}} \text{ to } T, \text{ after at most } |C_{\text{req}}| \text{ cycles, } C_{\text{req}} \subseteq T.

Proof sketch. The required capability set C_req for a bounded goal domain G is finite. Each planning cycle that encounters a capability gap synthesizes at least one tool that covers at least one element of C_req \ T_k. Since C_req is finite and each cycle reduces the gap by at least one element, after at most |C_req| cycles, the gap is empty. From that point forward, no new goals in G require tool synthesis, so T stabilizes.

The convergence rate depends on the diversity of goals encountered. If goals arrive in order of decreasing novelty (most novel first), convergence is fastest. If goals arrive uniformly at random from G, the expected convergence time follows a coupon collector distribution with expected value |C_req| · H(|C_req|), where H is the harmonic number.

E[K] = |C_{\text{req}}| \cdot H_{|C_{\text{req}}|} = |C_{\text{req}}| \sum_{i=1}^{|C_{\text{req}}|} \frac{1}{i} = O(|C_{\text{req}}| \log |C_{\text{req}}|})

11.1 Post-Convergence Dynamics

After convergence, the tool space does not become static. Tools continue to be refined through usage feedback: tools with high failure rates are regenerated, tools with overlapping capabilities are merged, and tools that have not been used for extended periods are deprecated. This post-convergence maintenance ensures that the tool space remains healthy and efficient, even as the goal distribution shifts over time.

The command-less architecture thus achieves a remarkable property: it starts with no pre-defined commands, grows its tool space organically through goal-driven synthesis, and converges to a stable, well-governed tool ecosystem — an ecosystem that is precisely adapted to the goals the agent actually encounters, rather than the goals its designers anticipated.

12. Conclusion

The command-less architecture represents a fundamental shift in how we think about AI agent design. By replacing the command registry with goal decomposition and dynamic tool synthesis, we enable agents that adapt to novel requirements at machine speed, maintain complete audit trails, and converge to stable tool ecosystems without human engineering effort. The MARIA OS implementation demonstrates that this architecture is not merely theoretical — it is practical, governable, and measurably superior to command-bound approaches for enterprise AI workloads. The key insight is counterintuitive: giving agents more freedom (the ability to generate tools) actually makes them more governable, because every generated tool carries provenance that command-registry tools lack. In the command-less world, the question shifts from 'what commands does the agent have?' to 'what goals can the agent achieve?' — and the answer is limited only by the governance boundaries we choose to set.