# Factorik

> Autonomous agents that build your product. Define an engineering agent once: its job, its repository, its rules. It wakes on an issue, a failed build or a schedule, works in an isolated sandbox and ships a pull request. The right to merge on its own is earned: an agent is promoted on its record, and moved down the moment one of its changes causes a problem.

## Earned autonomy

What sets Factorik apart: an agent's right to merge its own work is earned on its record, not switched on. Every agent works at one of three levels, and starts at the first.

- **Review everything** (one switch, off): Every change waits for a person, forever. The agent is fast and your team is the queue, however well it has done.
- **Trust everything** (one switch, on): Changes merge unseen from the first day, on no evidence. It is quick until one goes wrong, and then the switch goes off for all of them.
- **Earned autonomy** (factorik): Each agent holds exactly the trust its record supports: more as it proves itself, less the moment it stops deserving it.

1. **Opens pull requests.** Every pull request it opens waits for a person to merge it.
2. **Merges small changes.** Merges small changes by itself when the repository’s merge policy allows; larger ones wait for a person.
3. **Merges by policy.** Merges whatever the repository’s merge policy allows.

- **A record, not a feeling.** An agent moves up on what it actually shipped. 10 merged changes at a 85% merge rate with no problem caused in 30 days earns small merges; 25 at 90% earns everything your merge policy allows.
- **A person promotes it.** When an agent clears the bar, Factorik offers the promotion with the numbers, on the agent’s page and in Slack. Someone presses Promote or Not yet, and is recorded by name. Prefer hands off? Choose automatic promotion and the team is simply told.
- **Trust is lost at once.** A merged change is still watched. If it breaks CI on the default branch, fails to deploy, is reverted or is reported by a person, its agent drops a level immediately, and the team hears why on every channel.
- **Every step is on the record.** Each promotion and demotion is kept with who or what made it, when, and the numbers at that moment: an audit trail of how much the machine was trusted, and why.

## How it works

1. **Define it once.** Give an agent one job on one repository, and the rules it works by. Start from a preset, or describe the agent in your own words and Factorik drafts it from your codebase.
2. **It wakes on its own.** An issue is opened or labeled. The build breaks. A pull request needs a review. A schedule comes round, a webhook fires, or someone mentions it in Slack. Nobody has to be at a keyboard.
3. **It works in a sandbox.** Every run gets its own isolated machine with a copy of the repository and only the tools you granted. It reads, reproduces, changes and tests, and the machine is destroyed when the run ends.
4. **It ships, and earns more.** The work arrives as a pull request with a written summary. A new agent waits for a person to merge it; one that has earned it merges by itself, inside your merge policy.

## Agents you can start from

- **Bug Fixer**: When someone reports a bug or a production problem: diagnoses it with your production tools, fixes the cause and proves the fix, or writes up who needs to act.
- **Production Bug Hunter**: Without waiting for a report: checks production on a schedule, picks the bug hurting users most, and fixes it when the fix is small or medium.
- **Product Manager**: Each weekday morning: studies how the product is used and where it falls short, and proposes the next features and improvements. You choose what gets built.
- **Product Designer**: Weekly, or when you share a request or a vision: opens your app signed in, looks at it on a desktop and a phone, and proposes the design and UX fixes worth making. You choose what gets built.
- **Software Engineer**: Builds what you ask for (a feature, an improvement or a fix) the way the codebase already does things, with tests. Also builds the proposals you choose.
- **CI Fixer**: Wakes when the build breaks on the default branch, finds why and repairs it.
- **Maintenance Engineer**: Scheduled upkeep: finds one small, safe improvement each run and makes it.
- **Dependency Updater**: Weekly: updates outdated or vulnerable dependencies, one safe group at a time.
- **Test Writer**: Weekly: finds important logic with no test and covers it.
- **Code Reviewer**: Reviews every pull request, including the ones other agents open: runs it, reads it in context and says what must change.
- **Issue Triager**: First response to every new issue: checks the evidence, sizes it up and replies with what to do next. Never changes code.
- **Performance Engineer**: Weekly: measures what is actually slow in production and speeds up one thing, with before and after numbers.
- **Security Reviewer**: Weekly: reviews one area of the code for real security weaknesses, fixes the small certain ones and reports the rest.
- **Docs Keeper**: Weekly: finds where the documentation no longer matches the code and corrects it.

## Questions and answers

### What is Factorik?

Factorik is a platform for autonomous engineering agents. Each agent has one job on one repository: fixing reported bugs, repairing a broken build, updating dependencies, reviewing pull requests or proposing what to build next. It wakes on an event, a schedule or a message, works in an isolated sandbox, and opens a pull request. Agents earn their autonomy: each starts with a person merging its work, and is promoted to merge by itself as its record proves it can be trusted.

### How is Factorik different from other AI coding tools?

Two ways. First, a coding assistant waits for someone to prompt it, while a Factorik agent is defined once and then works on its own: an issue, a failed build, a schedule, a webhook or a Slack mention wakes it, and it delivers a finished pull request with a summary of what it did and why. Second, other tools make you choose between reviewing everything and trusting everything. Factorik measures each agent: it keeps a record of what the agent merged and whether any of it caused a problem, promotes the agent on that record and demotes it at once when a change goes wrong. That is earned autonomy.

### What is earned autonomy?

Earned autonomy is how a Factorik agent gains the right to merge its own work. Every agent works at one of three levels: "Opens pull requests" (a person merges), "Merges small changes" (it merges changes of at most 5 files and 100 lines by itself) and "Merges by policy" (it merges whatever the repository's merge policy allows). An agent starts at the first level and moves up one level at a time on its record: 10 merged changes at a 85% merge rate with no problem caused in 30 days for the second level, 25 at 90% for the third. A person approves each promotion, or the organization can choose automatic promotion. If a merged change breaks CI, fails to deploy, is reverted or is reported as causing a problem, the agent drops a level at once.

### Can an agent merge code without a person?

Only once it has earned it. A new agent opens pull requests and a person merges them. An agent promoted to a merging level merges by itself only what passes every rule of the repository's merge policy: the checks succeeded, the change is under your size limits (15 files and 400 lines by default), it touches no protected path (migrations, authentication, billing and CI configuration are protected by default), and every reviewing agent approved the current commit. Anything else waits for a person, and you can set any agent back to the first level at any time.

### Is my code safe with autonomous agents?

Every run works in its own isolated sandbox, which is destroyed when the run ends. The sandbox holds a short-lived token scoped to that one repository’s contents and has no authority to merge: pull requests are opened and merged by Factorik’s server, after a merge decision is recorded. You choose which repositories Factorik can see, credentials are encrypted at rest and never returned, and Factorik does not use your code to train AI models.

### Which AI runs the agents, and who pays for it?

Your organization connects its own AI provider account, and its agents run on that account. Usage is billed to you by your provider, on your terms with them, and Factorik shows what every run cost on the Spend page.

### What can agents do besides write code?

They review pull requests (including the ones other agents open), triage new issues, watch production for the bug hurting users most, and study how your product is used to propose features and design fixes. An agent that proposes changes nothing: a person decides which proposals get built.

### Which tools can an agent use?

The ones you grant it, and no others. Connect an error tracker, server logs, product analytics, a read-only database, your issue tracker or any MCP server, then grant each agent what its job needs. An agent can also open your web app with a test account to see what a user sees.

### Where does my code need to live?

On GitHub today. You install the Factorik app on your account and pick the repositories agents may work on; Factorik cannot see the rest.

### How do I get started?

Create an account, connect GitHub and pick a repository, add your AI provider key, and choose a preset agent or describe your own. Factorik is in early access, so signing up asks for an invite code: write to us and we will send you one.

## Links

- [Home](https://www.factorik.dev): what Factorik does and how it stays under your control
- [Get started](https://app.factorik.dev/signup): create an account (early access; needs an invite code)
- [Sign in](https://app.factorik.dev/login)
- [Terms of Service](https://www.factorik.dev/terms)
- [Privacy Policy](https://www.factorik.dev/privacy)
- Contact: factorik@gmail.com