AgentField Documentation

repository·main·Indexed 22 days ago

https://github.com/agent-field/agentfield

AgentField is an open-source AI backend and control plane for building and running AI agents as scalable microservices. It provides orchestration, routing, memory, and observability for multi-agent workflows. The documentation covers control plane setup, Decentralized Identity (DID) database schema migrations, Web UI development using React, and installation and release automation scripts.

Tokens
214.7K
Snippets
376
Records
1.1K
Agent score
81%

What's inside AgentField

  1. Overview of AgentField Go SDK Modules

    main

    The SDK is organized into several functional modules:

    • agent: Used to build AgentField-compatible agents and register reasoners or skills.
    • client: Provides a low-level HTTP client for interacting with the AgentField control plane.
    • types: Contains shared data structures and contracts used across the SDK.
    • ai: Provides helpers for interacting with AI providers via the control plane.
  2. Overview of AgentField Desktop

    main

    AgentField Desktop is a companion application designed to manage your local AgentField environment. It provides a centralized UI to monitor the health of your local control plane, manage agent nodes on your machine, and view live execution activity. It also allows for one-click installation of curated agents.

    Key features include:

    • Dashboard: High-level summary of running agents, current executions, and success rates.
    • Agents Management: View and control the status (running, stopped, or unknown) of installed agents.
    • Activity Tracking: Monitor in-flight and recently finished workflow runs.
    • Agent Installation: Install agents from a curated catalog or directly from a GitHub repository.
    • Secret Management: Securely manage API keys and environment variables required by agents.
  3. Quick Reference of AgentField Examples by Language

    main

    AgentField provides example agents across Python, TypeScript, and Go to demonstrate various capabilities. Use this table to find the right starting point for your use case.

    Use CasePythonTypeScriptGo
    Getting Startedhello_worldinit-examplego_agent_hello_world
    Basic RAGhello_world_ragdiscovery-memory-
    Production RAGagentic_rag--
    Documentation Q&Adocumentation_chatbot--
    RAG Evaluationrag_evaluation--
    Deep Researchdeep_research_agent--
    Image Generationimage_generation_hello_world--
    Multi-Agent Simulationsimulation_enginesimulation-
    Serverless Deploymentserverless_helloserverless-hello-
    Verifiable Credentials-verifiable-credentials-
  4. Use the Databricks Node as an AgentField agent node

    main
    The Databricks Node is a Go-based implementation that exposes Databricks functionality as an AgentField agent node. Instead of hardcoding Databricks REST paths, SQL API request shapes, or serving endpoint URLs, other nodes interact with Databricks using stable capability IDs. This abstraction allows for more resilient and standardized agent communication.
  5. Use the AgentField Python SDK

    main

    The Python SDK (sdk/python) acts as a thin client for the control plane's REST API. It is designed for ease of use with the following features:

    • Execution Helpers: Provides both asynchronous and synchronous helpers for executing agents.
    • Type Safety: Includes type hints for common primitives to improve developer experience.
    • Installation: The project is PyPI-ready and managed via pyproject.toml.
  6. Use the AgentField Go SDK

    main

    The Go SDK (sdk/go) is an idiomatic client designed for high-performance agent orchestration. It is ready for consumption via go get and is organized into several key packages:

    • agent: Core agent logic.
    • client: Client implementation.
    • types: Shared data structures.
    • ai: AI-specific primitives.

    The Go SDK implements interfaces shared by the control plane, allowing it to integrate deeply with the agent mesh.

  7. Organize large agent projects using the `reasoners/` package

    main

    When an agent project grows to more than 4 reasoners, you should move them into a reasoners/ package to maintain clean architecture.

    <slug>/
    ├── main.py
    └── reasoners/
        ├── __init__.py
        ├── models.py               # All Pydantic schemas
        ├── helpers.py              # Plain Python utilities
        └── <domain>.py             # One AgentRouter per logical grouping

    Component Roles

    • models.py: Contains every Pydantic schema used in the system. This centralizes type-checking and prevents circular imports.
    • helpers.py: Contains plain Python utilities (math, prose rendering, etc.). Do not use decorators here. Use @app.skill() only if the function needs to be discoverable by the control plane for external calls. Internal logic should remain as plain Python to avoid decorator overhead.
    • <domain>.py: Defines an AgentRouter for a specific logical grouping of reasoners.

    Using AgentRouter

    An AgentRouter allows you to group reasoners. Its methods (ai, call, memory, harness) proxy to the main agent.

    Important Gotchas:

    • router.node_id and other data attributes do not proxy. You must read the node ID from the environment: NODE_ID = os.getenv("AGENT_NODE_ID", "<slug>").
    • The prefix argument in AgentRouter(prefix="...") controls namespacing. If prefix="clauses", reasoner IDs become clauses_<func_name>. Use prefix="" to keep them raw.

    Example Router Implementation:

    import os
    from agentfield import AgentRouter
    from .models import MyResult
    
    NODE_ID = os.getenv("AGENT_NODE_ID", "<slug>")
    router = AgentRouter(prefix="", tags=["domain_name"])
    
    @router.reasoner()
    async def my_reasoner(payload: dict, model: str | None = None) -> MyResult:
        return await router.ai(system="...", user=str(payload), schema=MyResult, model=model)

    Registering a Router in main.py:

    from reasoners import domain_router
    
    # ... inside app setup
    app.include_router(domain_router)
    import os
    from agentfield import AgentRouter
    from .models import MyResult
    
    NODE_ID = os.getenv("AGENT_NODE_ID", "<slug>")
    router = AgentRouter(prefix="", tags=["domain_name"])
    
    @router.reasoner()
    async def my_reasoner(payload: dict, model: str | None = None) -> MyResult:
        return await router.ai(system="...", user=str(payload), schema=MyResult, model=model)
  8. Understand the Trigger Dispatch Envelope

    main

    The Control Plane dispatches triggers using a specific envelope format. The SDKs automatically unwrap the event object, build the TriggerContext from the _meta field, and apply any configured transform function before delivering the payload to your handler.

    If a call is made directly (without the _meta envelope), the payload is passed through unchanged.

    {
      "event": { /* raw provider payload */ },
      "_meta": {
        "trigger_id": "tr_abc",
        "source": "stripe",
        "event_type": "payment_intent.succeeded",
        "event_id": "evt_123",
        "idempotency_key": "evt_xxx",
        "received_at": "2026-04-28T22:29:54Z",
        "vc_id": "vc_456"
      }
    }
  9. Handle inter-reasoner data flow and serialization

    main

    When using app.call(), you are crossing a serialization boundary.

    Crucial Gotcha: Even if you pass a Pydantic model into app.call(), the receiver will receive a plain dict. You must either:

    1. Reconstruct the model on the receiving side: Model(**payload).
    2. Render the data to a natural-language prose string before calling, as LLMs reason better over prose than serialized JSON.

    Data Formats:

    • Structured JSON: Use when the data is intended to drive code routing (e.g., if result.type == "X").
    • Natural-language string: Use when the data is intended to become context for another LLM.
    • Hybrid: Use JSON for code logic and prose for LLM context.
  10. How AgentField orchestration works

    main

    AgentField is a control plane that turns plain Python, Go, or TypeScript functions into production-ready microservices.

    Key orchestration features include:

    • Fan-out & Recursion: Using app.call(), an agent can call itself or other agents. This allows a single request to trigger a distributed tree of sub-tasks (fan-out) managed by the control plane.
    • Structured Output: Using app.ai(), you can request LLM responses that conform to a specific schema (e.g., a Pydantic model), ensuring typed AI judgment.
    • Human-in-the-loop: The app.pause() method allows an agent to suspend execution, wait for human approval via a webhook, and resume once approved.
    • Automatic API Exposure: Calling app.run() automatically exposes your decorated functions as REST endpoints.
    • Reliability: The control plane handles queuing, retries, and tracing for every branch of an execution tree, preventing timeouts and managing complex workflows without manual broker setup.
  11. Decompose agent workflows by cognitive jobs

    main

    When designing an agent orchestration, do not decompose by data flow (e.g., fetch → parse → analyze). Instead, decompose by cognitive jobs—the mental moves an expert makes. This produces smaller, more verifiable, and more independent reasoning slots.

    To perform cognitive decomposition, ask:

    • What does the expert read first vs. what do they ignore?
    • What context must they hold in mind for downstream steps?
    • What triggers them to go deeper (dynamism signals)?
    • When do they stop (budgets/gates)?
    • What is the output contract and who verifies it?
    • Which moves are mechanical (use Python/code) vs. judgmental (use an LLM reasoner)?

    Example (Invoice Intake):

    • Triage: Glancing at vendor/amount to decide if it's routine or unusual (Reasoner: .ai() slot).
    • Deep Dive: Pulling contract terms only if the triage signal is 'unusual' (Conditional branching).
    • Verification: Checking math and PO references (Pure Python, not a reasoner).
    • Approval: High-value invoices require a human gate.
  12. Snowflake node guardrails and security

    main

    The Snowflake node enforces several security and operational guardrails to protect data and manage resources:

    • Access Control: Defaults to read-only access using a dedicated Snowflake role with minimum required privileges.
    • SQL Restrictions: Enforces one-statement SQL only. In query_readonly, DDL, DML, file transfers, role changes, and stored procedure calls are explicitly denied.
    • Resource Management: Enforces row limits and query timeouts.
    • Execution Safety: Returns NEEDS_REVIEW if prompts or semantic context are insufficient for a safe execution.
    • Observability: Includes Snowflake request/query IDs in outputs when available.