DOCSEARCHbyAlgolia
Submit Docs

initializ AI Platform (AIP)

website·Indexed 32 days ago

https://docs.initializ.ai

An agent-centric platform for building, deploying, and governing AI agents. The platform supports self-hosting on Kubernetes, provides a CLI for CI-deployed agents, and features a Gateway for model routing and Model Context Protocol (MCP) server integration. It allows developers to define agent skills, manage secrets, set policies and guardrails, and configure autonomous schedules.

Tokens
154.9K
Snippets
453
Records
1K
Agent score
50%

What's inside initializ

  1. Overview of Initializ Workflows

    A workflow is a multi-step pipeline of agents where the output of one step can serve as the input for the next. Workflows allow for chaining tasks such as research, drafting, and triage into a single execution. They support non-linear paths through branching and human approval gates. Workflows can be created manually via a pipeline canvas or automatically by describing a goal in plain language.

  2. Overview of the initializ CLI

    The initializ CLI is used to deploy agents to the initializ AI Platform. It is designed to run within a CI checkout, sending the platform necessary metadata and image references without requiring the platform to access the git repository.

    • Forge Runtime: Reads forge.yaml, skill metadata, and forge build output.
    • Claude-Agent and Strands Runtimes: Use a deploy spec instead of forge.yaml.
    • CI-Managed Agents: Agents deployed via CLI are managed by the repository. Skills, model providers, channels, policies, and guardrails cannot be edited in the console (returns 403). However, environment variables and secrets remain editable via the console or the initializ agent secrets set command.
    # Typical CI job flow
forge build  →  docker build+push (workspace registry)  →  initializ agent deploy --wait

  4. Overview of Forge Platform Policy layers

    Forge agents use a three-layered policy system to bound the capabilities declared in forge.yaml. If an agent's declaration exceeds these bounds, the agent will either refuse to start (for egress, tools, models, and size caps) or skip specific components (for channels). Policies are read once at startup; changes require a process or pod restart.

    LayerPathSet ByScope
    system/etc/forge/policy.yaml (or FORGE_SYSTEM_POLICY env)SysadminEvery agent on the machine
    user~/.forge/policy.yamlDeveloperEvery agent run by that user on that machine
    workspacePath defined by FORGE_PLATFORM_POLICY envWorkspace OperatorThe single deployed agent

  5. Overview of Forge Egress Security Controls

    Forge implements layered egress security to restrict external domain access for agents at two stages:

    1. Build time: Generates allowlist artifacts and Kubernetes NetworkPolicy manifests for container-level enforcement.
    2. Runtime: Uses an in-process EgressEnforcer (Go http.RoundTripper) for outbound HTTP requests and a local EgressProxy for subprocess HTTP traffic (e.g., skill scripts, cli_execute).

    Allowed domains are resolved from three sources: explicit domains in forge.yaml, tool domains inferred from registered tools, and pre-defined capability bundles.

  6. Overview of Forge Framework Plugins

    Forge uses a plugin system to adapt specific AI agent frameworks (e.g., CrewAI, LangChain) to its build pipeline. These plugins handle three primary responsibilities: project detection, configuration extraction, and the generation of A2A (Agent-to-Agent) wrappers.

  7. Overview of the Forge Agent Runtime

    Forge is the open agent runtime that executes all agents built on the platform. It manages the execution of skills, tools, channels, egress policies, and auditing. Developers can use Forge to build skills, run agents locally, and debug production behavior.

  8. Introduction to the initializ AI Platform (AIP)

    The initializ AI Platform (AIP) is an agent-centric platform designed for building, deploying, and governing AI agents and multi-agent workflows within a user's own environment.

  9. Overview of Forge Embedded Skills

    Forge provides a set of built-in 'Embedded Skills' that allow agents to perform specialized tasks across development, project management, SRE, and research domains. These skills are registered using the forge skills add <skill-name> command and provide access to specific tools or scripts.

  10. Overview of Channel Adapters

    Channel adapters bridge messaging platforms (such as Slack and Telegram) to A2A-compliant agents. They normalize platform-specific events into a common ChannelEvent format, forward them to the agent's A2A server, and deliver responses back to the platform. Both supported channels use outbound-only connections, meaning no public URLs or ngrok are required for local development.

  11. Overview of Forge Context Compression

    Context Compression (powered by ctxzip) reduces the size of bulky tool outputs before they reach the LLM. It is a reversible process: repetitive or less relevant data is offloaded to a local store (.forge/ctxzip.db) and replaced by a marker (e.g., <<ctxzip:HASH note>>). If the LLM needs the offloaded data, it can call the automatically registered context_expand(hash) tool to retrieve the original content. This prevents context window flooding and truncation while maintaining end-to-end losslessness.

  12. Overview of the Governance and Security framework

    The platform uses a layered security model managed within the Governance area of the console. This area is accessible to org admins and security admins (a role assignable under Organization → Settings). The framework consists of the following components:

    • Events: Raw, per-invocation records of agent actions and platform decisions (allowed, blocked, or masked), including tool executions, network egress, LLM calls, guardrail checks, and quota denials.
    • Policies:
      • Security policies: Org-level and workspace-level definitions of denials, allowances, required guardrails, and numeric ceilings.
      • Compliance policies: Value-level rules for individual tool calls (allow, defer for human approval, or deny), consisting of an org-wide baseline with optional per-agent tightening.
      • Trust-mode floors: Minimum attestation and delegation mode requirements for registered tool operations.
    • Agent Identity: A portfolio of all agent identities, including attestation posture, enforcement state, reach, and lifecycle management (kill/resume, terminal revocation, delete).
    • Approvals: A personal user queue (My Approvals, located in the Build sidebar group) for tool calls deferred by compliance rules or account-connection consent prompts.
    • Posture: Aggregated enforcement trends, such as block rates, active rules, quota hits, and unused policy rules.
    • Usage and Quotas: Tracking of token spend and executions, including windowed token budgets that can gate agent invocations.
    • Tool Registry: An org-scoped catalog of admitted tools. Any tool reference not in the registry is rejected during skill saving or agent building.