AI agent development
AI agents that work inside a governed workflow.
We build specialised agents for the repeatable, verifiable jobs in your delivery process and your product. Each one reads and writes artifacts, so its work is bounded, reviewable and replayable.
Start a project- artifact types agents read and write
- 11
- decisions made in chat history
- 0
- of agent jobs logged with their actor
- 100%
Why agents built this way are different
-
Bounded by skill and policy
Every agent runs with the skill files and policy definitions that say what it may do. It cannot wander outside its job.
-
Artifacts in, artifacts out
Agents do not talk to each other through conversational memory. They read the record of the previous state and write the record of the next one.
-
Reviewable, every time
An agent output is a job result attached to a run. A person can read it, reject it or approve it at the gate.
-
Replayable
Because every decision is in the record, a run can be replayed with a different agent, model or policy and the outcomes compared.
-
Runs where you want it
Agent jobs execute on managed runners or on your own. Your data stays where your runners are.
-
Audited by default
Every transition and job carries its actor: user, agent, system or runner. Compliance questions have answers.
When you are ready for agents
Agents pay off on work that is repeatable, verifiable and bounded. These are the signs you have it.
- 01
The same research is done every time
Requirements gathering, competitor checks, data pulls and summaries that follow the same shape for every request.
- 02
Drafts wait on a busy person
PRDs, design notes, test plans and documentation sit in a queue when a first draft could be produced in minutes and reviewed in ten.
- 03
Classification and routing are manual
Tickets, documents, leads or requests are read by a person only to decide where they go.
- 04
You tried a chatbot and could not trust it
Outputs were plausible, unbounded and unrecorded. You need the opposite: narrow jobs with reviewable results.
- 05
Compliance asks what the AI did
You need to show which model did what, with which inputs, approved by whom.
- 06
Your developers already use AI, invisibly
The work is happening; the record is not. Governance has to catch up with practice.
Do two or more of these apply? Tell us which ones and we reply with how we would run it.
Agents we build
-
Delivery agents
Research, PRD, design, implementation and QA agents that run as jobs inside the Sydeso workflow for your own projects.
-
Product agents
Agents embedded in your application that classify, draft, extract, summarise and act, with their work recorded.
-
Operations agents
Routing, triage, monitoring and reporting jobs that run on a schedule or on an event and write what they did.
-
Skill and policy definitions
The files that bound each agent: what it knows, what it may touch, what it must never do.
-
Evaluation and replay
Harnesses that re-run recorded jobs against new models or policies and report the difference.
-
Human gates
The approval and review steps that put a person between an agent and anything that matters.
How an agent engagement runs
- 01
Discovery
We map the jobs that are repeatable and verifiable, and the ones that are not. The ones that are become the first feature requests.
In the record feature_request per agent job, success measures
- 02
Skill and policy design
For each agent we write what it reads, what it writes, and what it may never do. You approve the policy before any agent runs.
In the record skill_file, policy_definition, design_package
- 03
Design approval
A human gate. The policy is the scope, and the run waits for your approval of it.
In the record design_approval transition
- 04
Build and bound
The agent is implemented as a job on a runner, with its inputs and outputs typed as artifacts.
In the record implementation_package
- 05
Automated QA and manual review
Recorded inputs are replayed through the agent. QA writes a report; a person reviews outputs at the second gate.
In the record qa_report, review_report
- 06
Release and watch
The agent goes live inside the workflow or your product. Every job it runs is logged with its actor, and drift shows up in the record.
In the record release_candidate, released, audit log
Governed agents against the alternatives
| Item | Chat assistant | Agent framework | Sydeso agents |
|---|---|---|---|
| Scope | Whatever the prompt says | Whatever the code allows | Skill files and policy definitions, approved by you |
| Memory | Conversation history | Vector store or scratchpad | Artifacts in the workflow run |
| Review | Read the chat | Read the logs | A human gate with the output attached |
| Audit | None | If you build it | Every job and transition, with its actor |
| Replay | No | Partial | Re-run recorded inputs against a new model or policy |
| Where it runs | Vendor cloud | Your choice | Managed or self-hosted runners |
Three ways to work with us.
-
For a team that needs the application built and run
Partner engagement
We own the application end to end: discovery, PRD, design, build, QA, release and operation. You hold the approval gates.
- Priced per project, scoped at discovery
- Your gates, our runs
- We operate production after launch
-
For a team that wants to run AI-driven delivery itself
Hosted platform
Your team and your feature requests on the Sydeso platform, with managed runners, storage, backups and upgrades operated by us.
- Per workspace, monthly
- Managed runners
- Support from the people who built it
-
For a team that keeps everything on its own infrastructure
Self-hosted
Clone the repository and run the same platform on Postgres, Redis and S3-compatible storage. Free under BUSL-1.1, AGPL-3.0 from 2030.
- Free
- Your runners, your data
- Community support on GitHub
Questions
- Which models do you use?
- The ones that fit the job and your policy. Model choice is part of the design package you approve, and the record shows which model ran each job, so switching later is a re-run, not a rewrite.
- Can agents run on our infrastructure?
- Yes. Runners are self-hosted or managed. A self-hosted runner executes agent jobs inside your network and writes artifacts back to the run.
- How do you stop an agent doing something it should not?
- Policy definitions bound what each agent may read and write, and two human gates sit between agent output and anything that ships. Nothing moves state without a transition, and every transition has an actor.
- Do we need the whole platform to use one agent?
- Agents are jobs on runners inside a workflow run, so they need the workflow. The platform is free to self-host and the hosted version is per workspace, monthly.
- How quickly do you reply?
- By email, with how we would run the work, not a call to book a call. Send one paragraph about what should ship first and you get a written answer.
- Do we have to use the Sydeso platform?
- Every partner engagement runs on it, because the record it keeps is how we work. You can host it yourself from day one or move to self-hosting later; the platform is public under BUSL-1.1.
- What happens to the work if we stop?
- Everything is in the record as artifacts: requirements, design packages, implementation packages, QA and review reports. You keep all of it, and the platform that reads it is yours to run.
Name the job.
Tell us the repeatable work you want an agent to do and we reply with the skill, the policy and the gates we would put around it.
Start a project