AlgorithmShift

Foundation

Agent builder
bring your own specialists.

The ten built-in agents cover most software-delivery work. For everything else — domain reviews, compliance checks, internal APIs — author your own agent in YAML and drop it into the same handoff graph.
Custom promptsTool plug-insApproval policyTestable
Book a deep-diveSee built-in agents
agent spec — custom compliance-review agentyaml
id: compliance-review
label: Compliance review
tier: sonnet
escalation_tier: opus
max_tokens: 8000

prompt: |
  You are a compliance auditor. Given a generated migration
  and requirement spec, flag any PII handling that violates
  the tenant's data-residency policy.

tools:
  - internal_api: /v1/tenants/{id}/data-policy
  - search_logs: audit/*

approval_mode: human
approval_criteria:
  require_reviewer_role: security_lead

The problem

Every team has work only their team knows how to do — a compliance check that cites your policy, a data-residency audit, a domain-specific code review. AlgorithmShift's built-in agents can't learn these for you. Agent builder lets you write them in YAML, plug them into your tools, and have the same orchestration graph run them alongside everything else.
[01]

Prompt, model tier, escalation — all in one file.

An agent is a YAML file that declares a system prompt, a model tier (Haiku / Sonnet / Opus), and an escalation fallback. No orchestration boilerplate. No surrounding Python.
  • Haiku for cheap, latency-sensitive runs
  • Sonnet for structured reasoning
  • Opus for high-stakes decisions
  • Escalation tier retries automatically on parse failures
behavior.yamlyaml
tier: sonnet
escalation_tier: opus
max_tokens: 8000
temperature: 0.2
retries: 2

prompt: |
  You are a compliance auditor. Given a generated
  migration + requirement spec, flag any PII handling
  that violates the tenant's data-residency policy.

  Return JSON matching the compliance-report schema.
[02]

Tool plug-ins — HTTP, SQL, shell, internal APIs.

Give the agent access to whatever its job needs: your REST APIs, an internal service, a read-only database, even a local shell command. Every tool call is logged alongside the run.
  • HTTP tools with auth via secrets manager
  • Typed DB tools (read-only by default)
  • Shell tools for linting, validation, and wrapping existing scripts
  • Every call captured in the audit log
tools.yamlyaml
tools:
  - http:
      name: jira_search
      base_url: https://acme.atlassian.net/rest/api/3
      auth: secret(JIRA_API_TOKEN)

  - internal_api:
      name: tenants.data_policy
      path: /v1/tenants/{id}/data-policy

  - db:
      name: read_slow_queries
      connection: env(DB_READONLY_URL)
      sql: |
        SELECT query, calls FROM pg_stat_statements
         ORDER BY total_exec_time DESC LIMIT 20

  - shell:
      name: lint_migration
      command: npx sql-lint {file}
[03]

Approval policy — auto, human, or gated by cost.

Declare when a human needs to sign off, and who. The orchestrator pauses the graph until the named reviewer decides. For routine work, auto-approve with guardrails on cost, tokens, or tool usage.
  • Role-based reviewer requirements (Security Lead, DBA, etc.)
  • Multi-reviewer consensus for prod-touching work
  • Auto-approve with cost + tool allowlists for low-risk routines
  • Rejection routes feedback back to the agent
approval.yamlyaml
approval_mode: human
approval_criteria:
  require_reviewer_role: security_lead
  required_reviewers: 2
  artifacts:
    - schema_diff
    - affected_tables

# Or auto-approve with guardrails:
approval_mode: auto
approval_criteria:
  max_cost_usd: 0.50
  max_tokens: 12000
  require_tool_allowlist:
    - read_slow_queries
[04]

Graph integration — same contracts as built-in agents.

Custom agents consume the same typed artifacts upstream agents produce, and emit the same shapes downstream agents expect. Once you publish one, it's addressable by slug from any workflow.
  • Reads schema entities, design tokens, release bundles as typed inputs
  • Hands off to downstream agents via typed output schemas
  • Published agents appear in the agent picker for every workspace
workflow.yaml — using a custom agentyaml
steps:
  - id: schema
    agent: schema
    depends_on: [spec]

  - id: compliance
    agent: compliance-review   # ← your custom agent
    depends_on: [schema]
    approval: human

  - id: apply
    agent: migrations
    depends_on: [compliance]
[05]

Testable before you ship.

Agents come with a fixture-based testing framework. Give it the input payload, assert on the decision or output fields, run locally or in CI before publishing to the workspace.
  • YAML-based test cases with fixture inputs
  • Assertions on output fields, token budget, tool calls
  • Run in CI via npx @algorithmshift/agent-test
agent-tests/compliance-review.test.yamlyaml
# Drop into .algorithmshift/agent-tests/compliance-review.test.yaml
cases:
  - name: flags EU PII in non-EU region
    input:
      spec: ./fixtures/eu-pii-spec.md
      migration: ./fixtures/mig_store_emails.sql
    expect:
      decision: fail
      findings_include: "residency"

  - name: passes for region-matched data
    input:
      spec: ./fixtures/us-pii-spec.md
      migration: ./fixtures/mig_us_emails.sql
    expect:
      decision: pass
[06]

Versioning + rollback.

Agents are versioned on publish. Workflows pin the version they use, so improving an agent doesn't surprise a live pipeline. Roll back to any prior version in one click.
  • Semver-style versions (v1.2.0)
  • Pin version per workflow
  • Changelog + diff between versions in the UI
agent.lockyaml
# pinned in each workflow so upgrades are deliberate
agents:
  compliance-review: "1.2.0"
  schema:            "latest"
  pages:             "3.4.1"

3 tiers

Model tiers

Haiku · Sonnet · Opus

4 tool kinds

HTTP · DB · shell · API

all audited

YAML

Spec format

no code required

CI-tested

Fixture tests

before publish

FAQ

Common questions

Can I bring my own model?
Enterprise customers can route a custom agent to a hosted model on their own infrastructure via an OpenAI-compatible endpoint. Free and Team tiers use our model pool (Anthropic Claude currently).
Can agents call each other?
Yes. Compose at the workflow level — one agent's output becomes another's input. For dynamic branching, agents can return a structured `next_agent` field the orchestrator respects.
How do I share an agent across workspaces?
Publish to your tenant's agent library (Enterprise) or keep it in one workspace and copy the YAML into another. An agent marketplace is on the roadmap.
What happens if my tool endpoint is down?
Tool calls have per-tool timeouts + retries. A persistent failure marks the agent run as `failed` with the error attached — the orchestrator can retry the whole step, or the reviewer can manually advance it.

See the full platform in action.

Bring a real requirement. Watch it become a running app you can ship.

Start freeBook a demo