People approve every change.
SylvieSI proposes. A person approves the exact change.
THE SHRIKS makes SylvieSI
THE SHRIKS is a technology company working across system architecture, AI and software infrastructure. SylvieSI is its main product: software that finds the cause of the bugs users report and prepares the fix, and gathers the feature requests users send into decisions.
SylvieSI was called SylvieAI before. It is the same product, made by the same company.
SylvieSI is software from THE SHRIKS for teams that ship a web product. It reads bug reports and feature requests from your app, Slack and Gmail, reproduces each bug, finds the cause and prepares the fix. A person approves every change. SylvieSI then tells the user who reported it, after the fix has been checked.
User feedback should become shipped work
Users tell software teams what is broken and what they need. The message lands in email, chat or a support tool. Someone has to read it, reproduce it, decide, write a ticket, build the change and write back. Much of that work stalls between teams.
SylvieSI does that work. Mobius reads and sorts what users send. Ouroboros finds causes, prepares changes and checks them. Sylvie is the workspace where your team directs both.
Your engineers and product leads stay in charge. They approve each change, and nothing merges or ships without them.
Explore the product ↗Request access ↗How we make product decisions
These principles shape what we build and how we describe it.
People decide
Nothing merges on its own.
Code changes arrive as draft pull requests. A person merges them.
Agents cannot act alone.
Agents read, investigate and propose. Controlled services carry out approved actions.
Senders hear back
Senders hear the result.
The sender is told the result on the channel they wrote from.
Told only when it works.
SylvieSI sends no fixed message before the fix is checked.
Original words stay.
Every request keeps the sender’s own message.
Limits are stated
Say when we do not know.
A cause is marked Verified, Probable, Insufficient evidence or Unable to determine.
Refuse what is unsafe.
A request that needs an unsafe change is declined with a reason and sent to engineering.
List what we have not done.
The Trust page states our limits, including the certifications we do not hold.
Safe by design
Workspace data stays separate.
Each workspace is separated at the database level.
Credentials stay protected.
Tokens are encrypted and kept out of the browser, the logs and model prompts.
Changes can be switched off.
A delivered change can be disabled, and the original page is checked in a browser.
Notes on how we build
The Journal explains how SylvieSI handles bugs, feature requests and approvals.
What SylvieSI covers
SylvieSI handles two kinds of work, each with its own path.
CREATE: feature requests
A feature request becomes an Idea, then an approved component on staging or a specification for engineering. SylvieSI checks it in a real browser.
REPAIR: bug reports
A bug report becomes a confirmed bug, a root cause assessment, a prepared fix and a staging check. The sender is told only after the check.
Learning from past cases
An investigation can start from earlier Cases in your workspace that had the same cause.
Founded by Laukik Rajput
Laukik Rajput founded THE SHRIKS and builds SylvieSI.
How it is tested
SylvieSI runs on a web product THE SHRIKS operates, through real Slack, Gmail and in-app channels. The test messages are written by our team. Pilot teams run it on their own products.
Contact THE SHRIKS
For product questions, pilot access, engineering collaboration and company enquiries.
Contact us ↗