#Recent updates

This page lists notable changes to Flezise, newest first. It opens with the capabilities available in the current release; later entries record what changes as each release ships.

#November 3, 2026

#Administrators can send a password reset link

The Members page has a new Send password reset link action for active members who sign in with a password. The member gets an email with a single-use link to choose a new password, so a forgotten password no longer needs a support request. See Members.

#Automations in projects with several repositories

An automation with the Repository tool now checks out the repository its name or instructions name, and its pull requests go to that repository. Before, a run in such a project could not start and could remove the project's local checkouts. See Create an automation.

#Features and tasks use an implement recipe instead of the bug-fix recipe

When Atlas classifies a ticket as a feature or task, it now applies the approved plan directly: reads the code, makes the change, adds or updates the targeted tests, and opens a pull request with a change summary and verification results. Before, features and tasks ran through the same investigate-and-reproduce recipe designed for bugs, which wasted the session budget trying to reproduce behaviour that was not broken. See Triage and execution.

#Video tutorials

A new Tutorials section collects narrated videos recorded on a real project, starting with bringing an existing codebase into Flezise and taking a Jira ticket to a pull request. A second video sets up a daily automation that keeps dependencies current and takes an upgrade to a pull request. Each video has chapters you can jump to, and each chapter links to the guide that covers it. See Tutorials.

#Atlas logs bugs reported in Slack, and answers each mention once

When you @mention Atlas in Slack and ask it to log, fix or look into a problem, it now creates a work item on the board, titled from your message. Before, it only replied, sometimes saying it had logged a ticket that didn't exist. Questions are answered in one thread reply instead of two, with headings, bold text, code and tables rendered instead of raw Markdown symbols. See Slack.

#Long interviews no longer stop with "Agent runtime failed"

An interview could stop partway with Agent runtime failed after Atlas repeatedly sent its stage check in a form the platform rejected. The platform now accepts that form, so the interview carries on to the requirements and architecture rounds. See Import a codebase.

#Atlas tells the ticket what it fixed

When Atlas opens a pull request for a Jira or Linear ticket, its comment on the ticket now says what caused the bug and what changed, in a sentence or two each, above the pull request link. Before, it only said a fix was done. See Jira.

#Connecting a codebase goes straight to the Ready checklist

After Connect & continue, the connect form now stays up with a spinner on the button until the Ready checklist opens. Before, an empty interview screen flashed for a couple of seconds in between. See Import a codebase.

#Platform-verified test runs use Atlas's environment

After Atlas finishes a fix, the platform re-runs its test commands with the environment Atlas recorded for them: the virtualenv it installed into and the settings for any database or cache it started. Before, the re-runs started from a bare shell and failed on import (ModuleNotFoundError) or a missing python before any test ran, so the pull request showed failed checks for a passing fix. The pull request's Platform-verified test runs section also renders properly on GitHub now. See Review a fix.

#The codebase audit stays readable for large repositories

The Codebase Audit now lists one row per module directory, with its languages, file count and entry points, instead of one row per file, and summarizes dependencies as a count per ecosystem. For a multi-repository project the report used to grow past a megabyte and stop rendering after the tech stack. See Import a codebase.

#Multi-repository tickets pick their repository before you approve

In a project with several repositories, Atlas now names the repository a ticket belongs to when it triages it, and execution uses that repository directly. If neither triage nor the ticket's text settles it, Submit plan says so and lists the candidates, so you can name one before approving instead of the run failing later. Runs in these projects also no longer fail at the end with "not a worktree of its project's checkout" after Atlas has made the change. See Plans.

#Jira webhook URL is now visible on the integration detail page

The Jira integration detail page now shows a Webhook URL card with a copy button and registration instructions. Previously the URL was only visible in the connect dialog, so OAuth users who closed it without copying had no way to retrieve it. Project members with read-only integration access continue to see the URL suppressed. See Jira integration.

#Knowledge Base search modes leave Agentic mode

Pressing Hybrid, Local, Global or Keyword in the Knowledge Base now switches out of ✦ Agentic, so your next query is a search. Before, the query still went to Atlas while the dimmed mode buttons looked selected. See Search the knowledge base.

#Brownfield onboarding now runs an intake interview grounded in the codebase scan

Connecting an existing repository via Existing codebase now gives you a direct path to the intake interview from the Ready checklist page. The interview is brownfield-specific: Atlas reads the codebase audit before asking questions, covers repository setup, deployment, external systems, must-preserve constraints, and what you want to change first, and does not ask discovery questions that the scan already answered. Onboarding is complete once you accept the baseline on the Ready checklist, not when the interview closes. See Import a codebase.

#Creation gate moves into the conversation and waits for Atlas to ask

The Product Brief creation gate card, with Approve and Not yet, now appears in the conversation pane, docked above the composer alongside the question and conflict cards, instead of the right-hand status rail. The card also no longer appears until Atlas has formally asked for approval in the chat, so the prompt and the agent's message arrive together. See The creation gate.

#The board stops asking you to finish an accepted baseline

After Accept baseline on the Ready checklist, the Baseline not accepted yet banner disappears right away. Before, it stayed on the board and other project pages until you reloaded. See Import a codebase.

#November 2, 2026

#The workflow diagram shows each spec and its build order

Once a project's work is split into specs, the workflow design's diagram draws one node per spec instead of a single SPEC node. Arrows show which spec waits for which, so specs side by side build in parallel. With System One workflow design on, the high-level design is now always kept, since the split depends on it. See Intake interview.

#Every designed screen names the requirements it delivers

A UI/UX design's Screen Inventory now lists, for every screen, the requirement ids it delivers, such as UC-2 or AC-3.1. A design model could leave them out before, and a feature planned from that design could not trace which screen covers which requirement. See Design canvas.

#Agent runs that start together keep their own model

Specs, code reviews and answers that start at the same moment in one project now each run on the model routed for them, and their cost lands on the right artifact. Before, both read whichever settings were written last: one run asked for DeepSeek and ran on Claude Haiku. See Model routing.

#The first run in a project with a dev environment gets time to start

The first agent run in a project whose repository carries a devenv.nix now gets up to 15 minutes to start, because it builds the project's toolchain before the agent can answer. Before, it was stopped after 6 minutes and the ticket failed with "failed health check within 360s"; a second try worked once the toolchain was cached. Other sandboxes keep the shorter limit. See Dev environments.

#Sessions in one project keep their own instructions

Two agent sessions that start at the same moment in one project, such as a UI design and a high-level design, now each read their own instructions and rules. Before, the second could overwrite the first's, so a session could run with the other's persona. See Model routing.

#A review that starts while its artifact is saving no longer fails

When an artifact's review started at the same moment its generation finished saving, the database could stop the review with a deadlock. The review now waits for nothing up front and simply skips, to be started again, if the artifact changed under it. See Review findings.

#A reviewer that never finishes its answer gets one fresh try

A reviewer whose answer is cut off at the model's output limit, as happens when a model loops in its reasoning, is now asked once more from scratch. If that is cut off too, the review lists the reviewer as failed instead of reading the half answer. See Review findings.

#A spec build that fails after merge reopens its ticket

If a merged spec build runs again and fails, its work item now leaves Completed and shows the failure. Before, the item stayed completed with an empty Outcome. A build waiting on the specs it depends on now says so in the item's activity, and the Spec step no longer repeats the branch and pull request shown under Outcome. See Board.

#A new project's interview starts on the first try

Opening the interview of a project you just created no longer fails straight away. The page prepared the project's command shell before the interview had set up the project's folder, the folder then could not be written to, and the chat showed an error on every retry. See Intake interview.

#The assistant answers what your project is about

Ask the assistant what your app is for, who its users are or what the PRD says, and it now reads your artifacts and answers. Before, a question like "what is the app for?" got the assistant's own list of what it can do, or an answer from the documentation that said it could not see your artifacts. See Atlas assistant.

#Artifacts generated together each use their own model

When two artifacts of a project start generating at the same moment, such as the UI design and the high-level design after the PRD is approved, each now runs on the model you routed for it. Before, one could pick up the other's model: a UI design ran on the Heavy Thinking model instead of the Visual one. See Model routing.

#UI designs no longer fail on every screen

Generating a UI/UX design now declares each screen's states, such as loading, empty and error, before the screens are drawn. Before, a design model could leave them out, every drawn screen then showed states nobody declared, and the whole design failed with no screens. See Design canvas.

#Artifact reviewers get past three minutes

An artifact reviewer that thinks for more than three minutes before it answers, as one can on a long PRD, now gets to finish. Before, its request timed out at three minutes every time and the review showed as failed. See Review findings.

#API providers wait as long as subscriptions

A request to OpenRouter or another API-key provider now waits up to 10 minutes for its answer, as Claude and Codex subscriptions do. Before, it gave up after 3 minutes, which a reasoning model can spend thinking. A stream that stops sending still ends after 2 minutes of silence. See AI providers.

#Every artifact reviewer runs your Artifact Review model

The reviewers in an artifact review, such as product coherence and requirement verifiability, now run the model you chose for Artifact Review. Before, only the review's chair did, and the other reviewers ran the Standard Work model. The step that rewrites flagged sections still runs on Standard Work. See Model routing.

#Reviews with many findings no longer fail

An artifact review that found a lot, such as one of a long high-level design, now reports its findings. Before, a result over 50 KB was cut short and the review showed as failed. See Review findings.

#Code review no longer reports a review that did not run as clean

When every code reviewer of a spec build failed to answer, the build showed code review as passed with no findings. It now shows as skipped, with the reason that the review could not run. See Code review.

#Building a spec again starts after a knowledge scan

Building a spec a second time no longer fails at the start with a git worktree error. The knowledge scan that follows a build used to take the build's branch for itself, and could remove the folder of a build still running on it. See Work the board.

#November 1, 2026

#Playbooks of your own, from your repository

Add .sdlc/playbooks.yaml to your repository to change the steps a ticket or a spec build goes through: your own checks (a script, an agent review that can follow a skill, or a call to your own service), agent and script steps, messages to people and to the ticket or pull request, and step types of your own. when: conditions and risk rules over named areas of your code decide which steps run, and the risk level shows next to the steps with its reasons. A failed check of yours goes back to the agent to fix, like the platform's own. See Playbooks.

#Work items show their playbook's steps

The Overview of a work item now opens with its playbook: the steps it goes through, in order, each marked done, in progress, failed, skipped or not started. Hover a step to see what it reported, such as how many fix turns a spec build's checks took. Tickets and spec builds follow two default playbooks that match how they ran before. See Work the board.

#Code review finishes on large builds

Code review now gets more time for a larger change: 8 minutes plus about 15 seconds per changed file, up to 30 minutes. The first build of a new project changes around 50 files and its review used to stop at 8 minutes and show as skipped. A build that waited for a free sandbox now starts as soon as one frees up instead of sitting stuck for about ten minutes. See Code review.

#Agent checks run on tickets, and area labels keep their checks

An agent: check in a ticket's playbook now runs and reports its verdict. Before, it failed every time with an error the agent could not fix. A ticket labelled with an area, such as phi, keeps that area's risk rules and checks after the change, even when the code lands outside the paths you mapped. See Playbooks.

#Tickets run in your project's environment

The agent now works on a ticket in the same sandbox as a spec build, with your project's toolchain from its devenv. Before, it ran in a sandbox without it and had to download packages to run your tests. See Work the board.

#Request changes on a ticket sends it back to the agent

Requesting changes on a ticket with a review note now has Atlas run again on the same branch and plan, with your note as its first instruction, also when its last run failed. Before, the ticket waited in planning and the note reached no one. When checks still fail after the agent's fix turns, every check now runs on the final code, so your review shows all of their results. See Review a fix.

#Watch live and Stop reach the agent that is working

Watch live, the messages you type there and Stop now reach the session the agent is working in, for spec builds, tickets and artifact reviews alike. Before, a spec build or a ticket could show and steer an idle session next to it, so your message waited until the run ended. See Work the board.

#Guards on Flezise's pull requests, before and after the merge

Flezise's checks are now tied to the commit they ran on, through a flezise/evidence commit status you can require, and run again when someone else pushes to the pull request. Open pull requests that start to conflict with the default branch are merged and resolved by the agent. After a merge, Flezise watches CI on the default branch and opens a fix, or else a revert, when it breaks. Changes to CI or check files always go to a person, and the pull request links a video of the agent's browser when there is one. See Pull requests.

#Approving shows that it worked, and review actions say what they do

After Confirm Approve, a confirmation appears in the bottom-right corner naming the artifact you approved, and the status badge changes in place, with only one green button on screen during the decision. Submit for Review is now Request review and asks for a quick confirmation, and an approved artifact with open findings reads "Approved · N findings noted" instead of "Not ready to approve". See Work the board.

#Interface responds as you work

Menus, dialogs and side panels now animate closed as well as open, keep keyboard focus inside while open, and tooltips wait a moment before appearing. Settings show Unsaved, Saving and Saved next to the save button and show errors inline, board cards lift when dragged and use larger meta text, and the inbox marks items that need your action. Animations follow your system's reduced-motion setting. The ? button in the bottom-left corner now opens a menu with the docs, keyboard shortcuts (or hold Alt), settings and release notes. See Work the board.

#Spec builds read like every other work item

A work item that builds an approved feature spec now has the same Overview as a ticket: the spec, the outcome, the verifications and your review. Its verifications also say whether the change was committed and where its pull request stands, as a ticket's do. A failed build shows why it stopped with Retry, and Request changes sends your note to the agent, which builds again on the same branch. See Work the board.

#One Code Quality verification

The two quality scans on a spec build now show as a single Code Quality verification. Its detail gives the quality score out of 100 and says when the build left stubbed or fake implementation code. Neither scan blocks the build. See Work the board.

#Accept & merge for spec builds without a pull request

In a project without a Git connection, accepting a spec build now merges its branch into the default branch and marks the spec merged, so work that depends on it starts. With a Git connection you still merge the pull request in your repository. See Work the board.

#Code review shows among the verifications

A spec build's Verifications now include Code Review: whether the agents' review found nothing, posted findings as comments on the spec, or sent serious findings back to the builder. See Work the board.

#October 31, 2026

#Archive work items instead of deleting them

A work item's menu, the bulk action bar and the item page now offer Archive. It takes the item off the board but keeps its history, plan, runs and branch, so you can come back to it. Turn on Show archived in the board's Display menu to see archived items and unarchive them. See Work the board.

#Watch a running work item and steer it

A running card on the board shows Watch live, which opens a chat with the agent doing the work. What you type there reaches the agent right after its current action, so you can correct it while it works, and you can attach files. The stop button, or Esc, halts the agent like Esc in a terminal agent: tell it what to do next and it carries on in the same session, or press stop again to end the run. The item page's Overview now holds the plan (click a step for its details) and the run's verifications, and Activity in the … menu shows what happened and what the agent is doing now. The item's Change Spec is approved with its plan and records the branch, diff and cost, so Review changes opens the diff on the spec. When the item needs review it is assigned to its reviewer, who gets a notification. See Work the board.

#The board follows merged and closed pull requests

When a pull request is merged on GitHub or GitLab, its artifact and work item now complete on their own and dependent work starts. A pull request closed without merging sends the work item back to planning. See Pull requests.

#Project chat answers sooner

Opening a project now starts its shell in the background, so the first chat there no longer waits about a minute before the agent replies. The shell stays up for an hour after the project was last used, and each use extends it. See The project shell.

#A walkthrough is one document

When you hand the browser back, your steps and up to twelve screenshots are saved as a single PDF instead of one file per screenshot. Take over and Hand back now switch at once, without the live view going blank. See Show the agent how you work.

#Finishing touches across the app

Settings sections that showed blank headings and descriptions now render their text, a run timeline that fails to load says so instead of reporting the run missing, and run statuses read "dead letter" instead of "dead_letter". Artifact and work item titles now use the body font while IDs stay monospace, artifact tree rows and pipeline nodes work from the keyboard, focus rings are consistent, and the inbox, runs and audit trail show placeholders while they load. Counts read "1 artifact" and "1 step", and the Knowledge Base tabs scroll on a phone. See Work the board.

#October 30, 2026

#Watch the agent's browser, take over, and show it how you work

In the interview and in project chat, the agent now has its own browser, shown in an Agent browser panel beside the conversation. Press Take over to sign in or walk through a task yourself; on Hand back the agent gets your steps and the walkthrough, with screenshots, is saved to the project's files for the knowledge base. Save sign-in keeps the login for the project's next browsers. See Agent web browsing.

#Linking a repository sets up its webhook

Link repository on a GitHub or GitLab integration now registers the repository's events webhook, or refreshes the one already pointing at Flezise, so issues, pull requests, comments and CI results arrive without copying a URL and secret by hand. If the token lacks permission to manage webhooks, the repository is still linked and the message names the missing permission. See GitHub integration.

#Choose which bots get answers

The Write-back card of GitHub, GitLab, Slack, Jira and Linear integrations has a Bots to answer field. Bot comments are still ignored by default; list the bot accounts the agent should answer anyway, or enter * for every bot. See GitHub integration.

#October 29, 2026

#Automations can start on integration events

An automation can now run each time a GitHub or GitLab issue, pull request or merge request is opened or commented on, a Slack or Microsoft Teams message is posted or the Slack bot is mentioned, or a Linear or Jira issue is created or commented on. Pick the channels or labels to watch from the connected account, and add an optional condition that System One, a fast decision model, checks before any agent starts. Set it up in the automation form or with swecli automation create --event. See Event triggers.

#Pull requests follow your template

A pull request the builder agent opens now fills in the repository's own pull_request_template.md, or GitLab's default merge request template, instead of a fixed layout. A repository without one can use the template you set under Settings → General → Pull request template. See Pull requests.

#Bots no longer get answers

Comments and messages written by bots, such as Dependabot or a CI app, no longer start an AI answer on GitHub, GitLab, Slack, Jira or Linear, and the agent never answers its own replies. This stops two bots from replying to each other and spending credits. See GitHub integration.

#October 28, 2026

#Trusted domains and secrets for the project shell

On Kubernetes, each project's shared shell now reaches only trusted domains and can no longer reach platform services or private networks. Organizations and projects add their own domains under Settings → Trusted Domains, and a project can store API keys under Settings → Secrets that are added to requests for their hosts without the commands ever seeing them. Changes reach running shells without restarting them. See Network access and secrets.

#Skill packs reach agents, and agents can propose skills

Skill packs a project subscribes to in the marketplace now reach its agents: coding and generation sandboxes copy them at launch, and project chat and automation runs search and load them while they work, so a newly subscribed skill is usable without restarting anything. An agent can propose a public GitHub skill; it waits under Your published packs until someone presses Approve. See Marketplace.

#October 27, 2026

#Uploaded and synced documents follow their source

Uploaded documents, pages synced from Confluence, Notion or SharePoint, meeting transcripts, tickets, chat threads and the scan-built codebase audit can no longer be edited or given a new version here; they change only when their source does, and every change is now kept as a version you can compare. A synced page held back by the quality check can now be approved or rejected, where before it stayed In Review for good. Replace File uploads a newer file into the same document instead of creating a duplicate, and a page deleted at the source is removed from the knowledge base on the next full sync. See Records of a source.

#October 26, 2026

#Requirements status names each requirement correctly

The Requirements status table on a PRD now takes each title from the line that defines the requirement, not from an earlier mention, and lists rows in document order. It now sits with the Requirements section instead of repeating under every section. See Traceability.

#Discard a draft you opened by mistake

Discard Draft in the artifact's overflow menu throws away an unwanted draft and puts the approved version back, so an accidental New Version no longer leaves the artifact stuck in Draft. The discarded draft stays in the version list. A draft you open is also no longer sent to review automatically after a minute; it waits until you press Submit for Review. The separate Compare button in the header is gone; View Changes in the same menu does the same job. See Discarding a draft.

#Design edits open a draft and can be rolled back

The design chat and canvas used to change an approved design in place, so there was nothing to roll back to. Now the first edit to an approved design opens a draft, shown in the header as soon as you send it, and Discard Draft puts the approved screens, theme and screen list back on the canvas. Discarding stops any design edit still running first, and the chat's stop button now stops the edit on the server too. See Designs.

#The stakeholder interview is a read-only record

The interview (INT-n) can no longer be edited, renamed, regenerated or given a new version; late answers update it and it stays approved. Each answer now shows who gave or decided it, and a Divergences & decisions section keeps every conflicting answer with the final decision, who made it and why. See Records of a source.

#October 23, 2026

#Automations

Automations run an agent on a cron schedule inside a project, unattended. Each run can notify project members or Slack and Teams channels, file work items for the pipeline to implement, open pull requests from its own checkout, flag something for human review, and keep a short memory between runs. An automation can be given a repository checkout, shell commands, web search and the project's MCP servers; it never approves anything. A dry run records what would happen without sending or creating anything, so you can verify instructions before going live. Three consecutive failures pause the automation and record why. The assistant can set up an automation from a plain-language description.

#Decision models in Experiments and Model Routing

A new experiment, System One decision model, switches on features that ask a decision model typed yes/no and choice questions instead of a language model. Turn it on under Experiments; a Decision row then appears in Model Routing to pick the provider and model. The provider is TypeSafe, a self-hosted model, or OpenRouter, which reuses the OpenRouter key you already connected and lists every decision model it offers. System One workflow design now also needs this switch.

#October 22, 2026

#Project cards show what needs you

Each card on the Projects home now shows how many items wait on you in that project and the latest thing that happened there, with its time, in place of the old progress bar. The bar counted approved documents, which says little about a product under continuous development.

#October 21, 2026

#A review workspace for work items

The work item page opens on an Overview tab that reads as a lifecycle timeline: the ticket, triage, the plan, the outcome and your review, in order. Plan, Changes and Activity tabs sit beside it. Edit the title and labels in place, and leave notes in the Activity composer. Ticket descriptions render as Markdown and long ones fold.

#Revise a plan from the current version

Revise plan opens the form already filled with the current plan's title, summary and steps, so you change what needs changing and submit it as the next version. While a plan waits for review, the button reads Request changes to revise the plan.

#Pick the repository for a source-control connection

The Source control card on a GitHub, GitLab or Bitbucket connection takes the repository as owner/repository, saves it and links it in one step.

#Ticket updates reach the knowledge base

When a tracked ticket changes in Jira, Linear or another connected tracker, its copy in the knowledge base is updated with the new title, description and status, so the assistant answers from the current version.

#Designs for command-line products

For a product with no graphical interface, the UI/UX design now describes terminal sessions and a command reference instead of web screens, and the builder agent uses that copy when it implements the commands.

#October 17, 2026

#Presentations

Ask the project assistant for a slide deck and Flezise builds an editable PowerPoint file from your project's documents, on your own template or the default one, with native text, charts and tables. The deck opens as a presentation artifact with a slide rail, a preview and a present mode, with the chat docked beside it. Decks follow the Brand Kit slide template and can also be exported as animated HTML.

#October 14, 2026

#Acceptance tests written before the build

When a story goes to implementation, the verifier agent writes black-box acceptance tests from its acceptance criteria before the builder agent starts, and the result is checked against the preview environment. A story gets three automatic attempts per approved version; a slice whose acceptance criteria the verifier flags as unclear waits for clarification instead of being retried.

#September 30, 2026

#Inbox

Notifications now have a page of their own. The inbox keeps everything addressed to you in a list you can read back, with the selected notification open beside it and a button to what it is about. You get a notification when someone assigns you an artifact or a work item, when someone mentions you in a comment, and when a new Flezise release ships, with its notes.

#Mentions

Type @ in a comment reply to mention a project member. They get a notification in their inbox that opens the artifact.

#September 17, 2026

#Automated code review

Every code change an agent produces is now checked by a panel of reviewer agents for security, performance, and quality problems, and for whether the change matches the requirement it came from, before a person reviews it. Critical findings can trigger a correction round first.

#Signed compliance evidence

A run can produce a signed, offline-verifiable evidence bundle: the audit trail, the model-call logs, the gate results, and the acceptance-criteria screenshots, mapped to EU AI Act and ISO/IEC 42001 controls.

#Preview environments

After an agent implements a change, Flezise brings the app up in a preview environment and hands you a URL to click through the running result. Multi-service stacks come up in full, so the change is checked against software that actually runs.

#Generated AGENTS.md files

Flezise generates an AGENTS.md for a repository from your approved specs, so any coding agent that works in the repo starts with the project's own coding standards, design, and interfaces.

#Pull request automation

A delivered change arrives as a pull request whose title and description are written from the approved story and the diff. An optional loop watches the pull request's checks and pushes fix commits when CI fails.

#Code intelligence from the CLI

The swecli platform command group exposes the code graph, context packs, and evidence verification that agents use, so you can query the same signals from your terminal.

#Dev environments per stack

Each project picks a stack, and the matching dev-environment pack installs its runtime, package manager, and tools before the agent runs, so a sandbox starts ready to build.

#Subscription model providers

Connect Claude, OpenAI Codex, GitHub Copilot, and Kimi through their subscription sign-in instead of an API key, and route work to them like any other provider.