AI agentswrite the code., review pull requests., analyze requirements., plan the tests., fix vulnerabilities., upgrade dependencies., assess release risk.write the code.review pull requests.analyze requirements.plan the tests.fix vulnerabilities.upgrade dependencies.assess release risk.Your rules decide what they can touch.

• analyst · developer · reviewer

  Feature development

  A ticket becomes a tested, review-ready pull request. The analyst asks what is missing, a policy routes the work, the developer implements on a branch and runs your tests, and review loops run until the reviewer is satisfied.

  1. Ticket
  2. Analyze
  3. Clarify
  4. Implement
  5. Test
  6. AI review
  7. Human review
  8. PR

  26 steps · up to 5 review cycles · $5 budget per run

• reviewer

  Code review

  A reviewer agent reads every diff before a person does, requests changes and checks the fix. Your reviewers get the diff, the test run and the AI review on one item.

• requirements-analyst

  Requirements analysis

  Reads the request, your docs and your code, then asks only what it cannot answer – in the app or as a comment on the original issue.

• bug-fix template

  Bug fixes

  Reproduce first. If the agent cannot, it asks the reporter. If it can, it fixes the bug, runs the regression tests and opens the PR behind a risk gate.

• test-planner

  Test planning

  Turns acceptance criteria into the automated and manual checks that would prove them, so QA starts from a plan instead of a guess.

• scheduled templates

  Upgrades and vulnerabilities

  Scheduled runs keep dependencies current and fix known vulnerabilities – updated, tested, scanned and signed off by a person before the PR opens.

• release-impact

  Releases to staging

  When a pull request merges, Tikla tests the release, explains what changed since the last deploy and where the risk is, deploys to staging and hands it to QA.

  1. Merged
  2. Tests
  3. Release impact
  4. Deploy to staging
  5. Manual QA

1. Step 1

   Step 1: Connect your tools

   Point a project at a repository and a tracker. A Linear or Jira issue, a merged pull request or a webhook can start a run, and a comment can answer a question.

2. Step 2

   Step 2: Describe the workflow

   Agents, approvals, reviews, conditions, policy checks, CI jobs and repository operations are all steps. Draw it in the builder or keep it as YAML next to the code.

3. Step 3

   Step 3: Let agents and people run it

   Agents analyze, implement and review in their own sandboxes. People answer, approve or take over where your rules say they must.

4. Step 4

   Step 4: Read the record

   Every run survives restarts and week-long waits. The timeline reads in plain language, and every decision keeps the rule that made it.

• Agents hold no credentials

  Model keys, git tokens and connector secrets live in the vault, a separate service with its own database. It makes every credentialed call itself and records each one.

• People sign what runs

  A workflow runs only as a version a person signed with a passkey, and the vault checks that signature before every step. Approvals ask for the passkey too.

• A sandbox for every step

  Each step’s commands run in a fresh container on a network of its own. The only way out is a proxy with the project’s allow-list.

• Tenants kept apart

  Every organization’s rows sit behind row-level security, and its secrets and content are sealed under keys of its own.

• Encrypted between services

  Every internal hop uses TLS 1.3 with a certificate on both sides. Only the edge has a published port.

• Zero data retention

  Model requests carry a zero-retention rule, so a provider that keeps or trains on prompts never serves them.

• An audit trail that explains

  Every state change lands in an append-only audit log, and every policy decision keeps the rule that fired and the inputs it saw.

• Single sign-on and SCIM

  OIDC single sign-on, SCIM provisioning and verified domains. An owner can make single sign-on the only way in.

• Engineering leaders

  Decide how much to automate per repository, see cost and cycle time per work item, and answer “why did the AI do that” with a stored decision.

• Platform teams

  Keep workflows, agents and policies as YAML next to the code, add your own steps over HTTP, and swap models without touching a workflow.

• Product managers

  Write the ticket, answer the analyst’s questions in Linear or Slack, and approve the result without learning what a token is.

• Security and compliance

  Rules gate risky paths, people sign with a passkey, every state change lands in the audit log, and production stays off until your rules allow it.

• Models

  • OpenAI
  • Anthropic
  • OpenRouter
  • Any OpenAI-compatible endpoint

• Repositories

  • GitHub
  • GitLab

• Work tracking

  • Linear
  • Jira Cloud and Data Center
  • Trello

• CI

  • GitHub Actions
  • GitLab CI
  • Test commands in the sandbox

• Chat

  • Slack
  • In-app inbox

• Agents

  • Built-in agents
  • Your own agents in YAML

• Knowledge

  • Retrieval over your code and docs
  • Your own retrieval endpoint

• Anything else

  • Inbound webhooks
  • Outbound HTTP actions
  • Custom steps over HTTP

Provider credentials are sealed in the vault and can be scoped to an organization, a workspace, a project or a single agent. Calls on your own keys cost nothing in credits.

.tikla/
  project.yaml
  agents/
    requirements-analyst.yaml
    developer.yaml
    reviewer.yaml
  workflows/
    feature-development.yaml
    bug-fix.yaml
    dependency-update.yaml
  policies/
    development-routing.yaml
    deployment.yaml

apiVersion: tikla/v1
kind: Workflow
metadata:
  key: feature-development
  name: Feature Development
spec:
  config:
    maxReviewCycles: 5
    budget: { maxCostPerExecutionUsd: 5.00, maxDurationMinutes: 1440 }
  defaults:
    onFailure: { action: goto, target: escalateToHuman }
  start: onIssue
  nodes:
    - id: onIssue
      type: trigger
      config: { source: linear, event: issue.created }
      next: analyze

    - id: analyze
      type: agent
      name: Requirements analysis
      config: { agentKey: requirements-analyst }
      budget: { maxCostUsd: 0.50 }
      next: needsClarification

    # needsClarification -> askBusiness -> analyze, until the
    # requirements are ready

    - id: prepareBranch
      type: repository_operation
      config: { operation: create_branch, branch: "tikla/${workItem.key}" }
      next: routingPolicy

    - id: routingPolicy
      type: policy_check
      name: Complexity and risk gate
      config:
        policyKey: development-routing
        inputs:
          work:
            complexity: "${steps.analyze.data.complexity}"
            risk: "${steps.analyze.data.risk}"
            confidence: "${steps.analyze.data.confidence}"
      branches:
        - when: "steps.routingPolicy.data.outcomes.route == 'human'"
          next: humanDeveloper
        - default: true
          next: implement

    # implement -> runTests -> aiReview -> openPullRequest
    # -> humanPrReview -> done

{
  "protocolVersion": 1,
  "callId": "0199a3c2-7b1e-7c4f-9d2a-3e5f6a7b8c9d",
  "test": false,
  "organizationId": "0199a3c2-0000-7000-8000-000000000001",
  "projectId": "0199a3c2-0000-7000-8000-000000000002",
  "executionId": "0199a3c2-0000-7000-8000-000000000003",
  "stepExecutionId": "0199a3c2-0000-7000-8000-000000000004",
  "workflow": { "key": "dependency-update", "version": 7 },
  "node": {
    "id": "securityScan", "name": "Security scan", "type": "custom_service",
    "contract": {
      "key": "security-scanner", "version": "1.0.0",
      "hash": "a815970be0581c058f5137b6bf818309f1536991af25f7909779949b54438410"
    }
  },
  "workItem": { "id": "0199a3c2-0000-7000-8000-000000000005", "key": "PAY-142" },
  "attempt": 1,
  "iteration": 1,
  "deadline": "2026-09-30T12:15:00Z",
  "inputs": { "repository": "https://git.acme.test/pay.git", "ref": "tikla/PAY-142", "changedFiles": ["pom.xml"] },
  "credentials": {}
}

{
  "protocolVersion": 1,
  "status": "COMPLETED",
  "data": { "verdict": "fail", "findingCount": 3, "criticalFindings": [ { "summary": "…" } ] },
  "meta": { "externalId": "scan-41", "externalUrl": "https://scanner.acme.test/runs/41" },
  "artifacts": [
    { "name": "scan.sarif", "type": "SECURITY_REPORT", "contentType": "application/json", "content": "…" }
  ]
}

• REST API

  Everything under /api/v1, with an OpenAPI specification.

• Webhooks

  Inbound per connection, and outbound notifications.

• Export and import

  A workflow moves between projects and reviews like code.

• API keys

  Service accounts and keys, scoped by permission.

Credits pay for model calls on the platform’s keys, attributed to the work item that made them.