How Swrly Works: Agent Teams vs Anonymous Chains

If you have worked with LLM frameworks like LangChain, CrewAI, or AutoGen, you have probably experienced this: your "agents" are really just sequential function calls with shared state. They do not have names. They do not have specialties. They are anonymous steps in a chain, and when something goes wrong, good luck figuring out which step failed and why.

Swrly takes a fundamentally different approach.

The Problem with Anonymous Chains

Most agent frameworks model workflows as linear pipelines. You define a series of steps, each one receiving the output of the previous one. The framework handles the plumbing. It looks clean in a tutorial, but in production it creates real problems:

• No role clarity. Every step is interchangeable. There is no concept of "this agent is a code reviewer" versus "this agent is a project manager." They are all just prompt-plus-tool combinations in a list.
• Debugging is painful. When a 7-step chain produces bad output, you have to trace through every step to find where things went wrong. There are no names, no boundaries, no clear ownership.
• Context bleed. Because agents share a single context window, earlier steps can pollute later ones. A verbose data-fetching step consumes tokens that your reasoning step needs.
• No conditional logic. Linear chains are linear. If you need branching — "if the review passes, deploy; if it fails, notify" — you are writing custom Python glue code.

This is not orchestration. It is scripting with extra steps.

Swrly's Approach: Named Specialist Agents

In Swrly, every agent in a workflow is a named specialist with a clear identity:

• A distinct role — "Code Reviewer," "PR Summarizer," "Deployment Manager"
• A tailored system prompt — instructions specific to that agent's job
• Its own tool access — each agent gets only the integrations it needs
• Configurable behavior — max turns, context accumulation, output format

When you look at a Swrly workflow, you can immediately understand what each agent does and why it is there. This is not a cosmetic difference. It changes how you design, debug, and maintain your automations.

The Visual Builder

Swrly workflows are built on a drag-and-drop canvas, not in YAML files or Python scripts. The builder gives you a spatial view of your entire workflow — which agents connect to which, where conditions branch, and how data flows through the system.

You add nodes by dragging them from the sidebar or using the command palette (Cmd+K). You connect them by drawing edges between ports. You configure each node by clicking it and editing its properties in the side panel.

This is not a toy. The builder supports:

• Undo/redo with full state history
• Auto-layout for organizing complex workflows
• Viewport persistence so your canvas position is saved between sessions
• Resizable configuration panels for comfortable editing
• Keyboard shortcuts and full accessibility support

Everything you build visually maps directly to the execution model. What you see is what runs.

Six Node Types

Swrly workflows are composed of six node types, each serving a distinct purpose:

Agent nodes are the core. Each one wraps a Claude-powered agent with a system prompt, tool access, and configurable parameters like maxTurns and accumulateContext.

Integration nodes connect to external services without needing an agent. Send a Slack message, create a Jira ticket, or fetch data from an API — directly, with no LLM call required.

Condition nodes enable branching logic. Define rules like "if the previous output contains APPROVED" or "if the sentiment score is above 0.8," and the workflow splits into separate paths. Six operators are supported: equals, not_equals, contains, not_contains, greater_than, and less_than.

Trigger nodes start workflows automatically. Configure a webhook URL, a cron schedule, or an event listener, and the workflow runs without manual intervention.

Loop nodes repeat a section of the workflow over a list of items — process each file in a PR, each row in a spreadsheet, or each message in a queue.

Approval nodes pause execution and wait for a human to review and approve before continuing. Critical for workflows where you want a human in the loop before deployment or notification.

37 Integrations, 318 MCP Tools

Swrly agents do not just talk to each other. They interact with the tools your team already uses. The platform ships with 37 integrations and 318 MCP tools spanning:

• Development: GitHub, GitLab, Bitbucket, Vercel, AWS
• Project management: Jira, Linear, Asana, Notion, Airtable
• Communication: Slack, Discord, Twilio, Microsoft Teams
• Monitoring: PagerDuty, Sentry, Datadog, PostHog
• AI/ML: OpenAI, Hugging Face
• Productivity: Google Workspace, Confluence, Trello

Each integration exposes specific tools — github_create_pr, slack_send_message, linear_create_issue — that agents can call during execution. You configure which tools each agent has access to, keeping the principle of least privilege.

BYOK: Your Claude Subscription, Not Ours

Here is something that matters a lot in production: Swrly does not charge you for AI usage.

Most platforms charge per-token or per-credit on top of the platform fee. With Swrly, you bring your own Claude Code subscription. You pay Anthropic directly for your AI usage ($20/month for Claude Pro). Swrly charges separately for orchestration features ($0-$99/month depending on your plan).

You paste your Claude Code session token in Settings. Swrly encrypts it with AES-256-GCM, stores it securely, and uses it ephemerally during execution. Your key is never logged, never shared, and never used outside your workflow runs.

Two separate, predictable bills. No surprises.

Real-Time Observability

When a workflow runs, you do not stare at a loading spinner. Swrly provides a real-time execution overlay directly on the canvas:

• Each node lights up as it executes — pending, running, completed, or failed
• Server-Sent Events (SSE) stream status updates with no polling
• Click any completed node to see its full output, token usage, and execution time
• The run history panel shows every past execution with timestamps and status

This is not a log file you parse after the fact. It is a live view of your workflow doing its job.

Example: A 3-Agent PR Review Workflow

Here is a concrete workflow you can build in Swrly in about 10 minutes:

1. Webhook Trigger — listens for pull_request.opened events from GitHub
2. Code Reviewer Agent — receives the PR diff, analyzes code quality, security issues, and style violations. Uses github_get_content and github_list_pr_files tools.
3. Condition Node — checks if the reviewer's output contains "APPROVED"
4. Slack Notification (approved branch) — posts to #shipped: "PR #42 approved by Swrly"
5. Slack Notification (revision branch) — posts to #reviews: "PR #42 needs changes" with the reviewer's feedback

The Code Reviewer agent's system prompt might look like this:

You are a senior code reviewer. Analyze the PR diff for:
- Security vulnerabilities
- Performance issues
- Code style violations
- Missing error handling

End your review with either APPROVED or NEEDS_REVISION followed by
a summary of your findings.

No Python. No YAML. No deployment scripts. You build it visually, test it with a real PR, and it runs.

Who Is This For?

Swrly is built for engineering teams that want to automate complex, multi-step workflows involving AI reasoning. If you are:

• Manually reviewing PRs and posting summaries to Slack
• Writing one-off scripts to triage bugs across Jira and GitHub
• Building internal tools that need LLM reasoning in the middle
• Running AI-powered QA pipelines that need human approval gates

Then Swrly replaces the glue code, the cron jobs, and the fragile scripts with a visual, observable, maintainable system.

Start Building

Swrly is free to start. No credit card required. Sign up at swrly.com, create your first swirl, and see what named specialist agents can do for your team.