Meet Sylliptor: an autonomous coding agent that handles big workloads in one run

We're releasing Sylliptor, the first product from Alysis AI: a coding agent built to take on large repo changes, not just answer questions about them. Its Forge workflow can plan the work, split it across swarm workers, run an integration gate, and help bring the result back into a real codebase.

The larger thesis is simple: AI gets more useful when the agent layer is open, local, and not tied to one model vendor. Sylliptor uses the OpenAI protocol, runs in your terminal, and lets you choose the model that fits the job.

Sylliptor is where we start.

Why we named it Sylliptor

The name comes from Ancient Greek: συλλήπτωρ — someone who helps, assists, or takes part in an action, often as a partner in a specific endeavor. A collaborator, not a replacement. That framing is the whole point: Sylliptor sits inside your terminal, plans alongside you, executes inside a sandbox, and the work stays yours.

Introducing Forge

Most coding agents top out at small edits. Forge is built for the work that doesn't fit in a single chat: a structured plan, parallel workers, an integration gate before anything lands, and replanning when something breaks. You describe what you want. Forge breaks it down, runs it, checks it, and brings back a candidate you can actually merge.

What Sylliptor is

Sylliptor is a CLI coding agent. It works inside your repository, uses the OpenAI protocol for model access, and can use the repo itself, including git history, when a task is too large for a single chat loop.

pipx install sylliptor-agent-cli
sylliptor                       # interactive chat
sylliptor run "Fix the failing test in tests/test_auth.py"
sylliptor forge plan            # structured planning workflow

That's the full install. No account, no telemetry, no required login. Your model, your machine, your code.

The runtime keeps a local audit trail, can rerun verification commands after edits, and is built for longer sessions where tool output and context need to stay manageable.

Why it's different

It runs on any model

Sylliptor ships with 24 provider presets that route through the OpenAI protocol. You can point it at a hosted provider or a local endpoint without changing how you work.

The useful part is not only switching providers. A Forge workflow can assign different roles to different models. You can pick a different model for each subagent — a stronger one for planning, a cheaper one for routine edits, whatever fits the role.

Forge handles the work, not just the chat

Forge turns a large request into a structured plan before code changes start. The plan has tasks, file scopes, acceptance criteria, dependencies, and status. That gives the agent a working shape for the project instead of one long prompt trying to hold everything at once.

When the plan is ready, Forge can execute tasks through parallel swarm workers. Each worker gets the part of the repo it needs, plus the relevant instructions from the plan. That matters for changes like moving an auth flow from one API shape to another, where the work touches product code and tests.

Before a batch lands, the integration gate checks the combined result. If verification fails, the batch does not merge into the main workspace. Forge can replan from that evidence, keep the failed work isolated, and try again with a clearer task.

Conflict resolution is part of the workflow too. When swarm workers touch overlapping files, Forge has a path for reviewing and resolving the conflict instead of pretending parallel edits never collide.

The practical goal is simple: give a user a way to ask for a real repo change, watch it become a plan, and get a verified candidate back instead of a pile of half-related edits.

First-class multimodal Forge Assets

Large coding tasks often start with more than text. Forge Assets let you attach screenshots or documents to a run, then keep that context tied to the plan.

Sylliptor can extract text from documents and summarize images for models that need it. The planner can use those assets while building the plan, and workers can receive the relevant assets when they execute their tasks.

For example, you can attach a screenshot of a broken UI state and ask Forge to fix it. The screenshot stays part of the workflow instead of disappearing after the first chat message.

A self-extending agent

Skills are reusable SKILL.md bundles that teach Sylliptor a workflow for a project or domain. A team can add a skill for its release process, review checklist, or repo conventions, and Sylliptor can discover it in future sessions.

Plugins are larger bundles that can ship skills, custom tools, MCP servers, and hooks together. They are pinned and trust-gated so teams can extend the agent without turning install time into a free-for-all.

It sandboxes by default

By default, shell commands and verification run inside a sandbox. Sylliptor uses Bubblewrap on Linux when available, Docker otherwise.

Network access is off unless you choose to enable it. If the configured sandbox backend is not available, Sylliptor fails closed instead of silently falling back to the host shell.

MCP with sane trust boundaries

Sylliptor supports MCP, but treats it as a trust boundary. Tool descriptions are sanitized before they reach the model, and MCP OAuth tokens are stored encrypted instead of living in plain project config.

Built in Python

Sylliptor is written in Python 3.11+. That is where much of the AI tooling ecosystem already lives, and it keeps the agent approachable for teams that want to read, fork, or extend it.

Where it helps

Sylliptor is useful when a task is big enough that a normal chat agent starts to lose the thread. A refactor that touches several parts of a repo can become a Forge plan, then move through execution and verification in batches.

It also helps when model choice matters. You can use a stronger model where the task needs judgment and a cheaper one where the work is more mechanical, all inside one workflow.

For teams working with screenshots or repo-specific conventions, Sylliptor can keep that context close to the work. It is still a CLI, but it is meant to behave like it belongs inside the repo rather than beside it.

Why we're building this

We want coding agents to be available to more people, at a lower cost, without hiding the important parts behind one vendor or one interface. That means running locally, choosing models, and keeping the workflow close to the repo.

Forge is the center of that. Someone without deep coding experience should be able to describe a project and get a plan that can actually move through the repo. Someone with experience should be able to take on changes that would be too tedious to manage by hand.

Sylliptor can read git history, inspect the current codebase, and work inside the same repository you do. It is not a replacement for judgment, but it should make larger work feel possible.

We're shipping it open-source under Apache 2.0 so teams can inspect it, change it, and build on it.

Try Sylliptor → sylliptor.alysisai.com

Drawbacks

A few things to know before you start:

This is the first public release.

Forge can still miss edge cases. The plan may be too broad, or a worker may solve its part without seeing a dependency in another part of the repo. When that happens, the integration gate should catch the failure and keep the batch from landing, but the user may need to replan or give sharper direction.

Swarm execution is not magic parallelism. It works best when tasks have clear boundaries. If several workers need the same files, conflicts can still happen. Sylliptor has conflict resolution paths, but messy conflicts may still need a human to decide the right answer.

Replanning depends on good evidence. If the verification command is weak or missing, Forge has less to learn from. The workflow is much better when the repo has useful tests, linting, or another concrete check.

Assets are helpful, not perfect. OCR and vision summaries can miss details. If an attached screenshot or document is central to the task, you should expect to inspect the result and correct the agent when the asset was misunderstood.

What's next

Sylliptor is the first step. Next, we want to offer cheaper inference and more tools that are available to people wherever they are, not only to teams with large budgets or narrow vendor access.

Get started

Visit Sylliptor →

pipx install sylliptor-agent-cli
sylliptor                       # opens the 3-step setup wizard, then chat
sylliptor sandbox setup         # pull/check the Docker sandbox image
sylliptor sandbox doctor --smoke  # verify your sandbox is ready
sylliptor forge plan            # try the planning workflow

• Site: sylliptor.alysisai.com
• Source: github.com/AlysisAi/sylliptor
• Docs: Quickstart · Reference · Forge · Sandbox · Security
• License: Apache-2.0
• Issues: open one in the repo

We're shipping this early on purpose. If you try it and something breaks, open an issue with the session log path — they're rich enough that we can usually reconstruct what happened.

Pick your model. Run it locally. Keep your code yours.

— The Alysis AI team