Questions worth asking.

No. RepoStaff is being built, and the product and every integration described here are planned. There is no live signup, checkout, or waitlist submission. Design partners come first.

Ephemeral agents will implement and validate scoped work. One renameable Marshall per organization will plan, triage, delegate, and check. The Management UI will oversee work, connections, approvals, spending, and outcomes. The brain repo you own supports all three.

No, and I won't sell it that way. It's for a team you already have, to add capacity for backlog work the team wants done and can't currently staff.

I don't know yet, and neither does anyone selling you an agent. Marshall has that job. The Management UI will show you how it's going.

Maybe. My unverified market hypothesis as of 2026-11-08: it was the only product I found that seemed to deliver all three pillars, and it's further along than RepoStaff will be for a long time. Running it in your own VPC takes their Enterprise plan, and what it learns lives inside their product. If neither bothers you, go buy it.

You shouldn't have to. Self-run is planned to keep the agents on infrastructure you pick, and the brain is already yours. If RepoStaff disappears, you still have the repo. Weigh the rest for yourself.

Cautious is the default; Balanced and Hands-off are alternatives. Human, agent, and CI gates will govern the fixed flow from triggered to merged, and you can set your own. Policy will live in the brain repo, and Management UI changes will become commits. Workers will read pinned brain snapshots and can't rewrite policy or broaden their own permissions.

Not automatically. An authorized chat request can create proposed work, and Marshall can draft the ticket. A proposal doesn't authorize execution. That still needs the configured authorization and gates.

They will be able to ask Marshall for something in plain language, and it will draft the ticket. A developer will decide when the work starts, unless your team has set it up differently.

Run your tests, bring up your app in Docker, use it in a browser, and attach evidence to the pull request: a test summary, plus screenshots or a recording when the UI changed. All planned.

The plan is short-lived scoped credentials, restricted network access by default, a read-only copy of the brain, and no production credentials.

No. Tests and relevant screenshots or recordings accompany the pull request to support review. They do not guarantee correctness.

No. The workflow ends at merge, not deployment. Agents get no production credentials, and nothing here deploys for you.

Yes. You'll be able to cancel a run from the Management UI, retry it, send it back with a comment, or abandon it. Budgets and per-ticket limits are planned to stop runs too.

org/, decisions/, memories/, skills/, and policy/. Plain files in a git repo in your org.

The sourced knowledge committed to your brain repo remains yours. Cloning it does not export application history, session archives, credentials, or live services. Those need separate export or migration, so take what you need before you go.

Yes. The plan is plain files: change the file and push.

Every memory will record where it came from. Agents will get a read-only copy and treat memories as information, never as commands. The launch plan also sends untrusted input to quarantine by default, which each org can switch off, and stops Marshall from loosening its own permissions without a human. None of that is built, and I don't know yet how well it will hold up against deliberately poisoned input.

You'll set that per org. The planned default lets memories through without approval and asks for it on skills/ and policy/. Loosening that is an explicit, audited choice.

An admin will start onboarding. Marshall will read your code, docs, CI setup, recent merged pull requests, and tickets, confirm what it worked out, and interview you on what it couldn't. Your answers will become commits in the brain, with their source. The target is 30 minutes for the admin, and nobody has timed it yet.

Yes. One Marshall per org at launch.

GitHub for code, CI, Issues, and the brain repo, plus Discord, come first. Linear and Slack come next, then Trello. Microsoft Teams is a stretch goal, not a launch commitment. These arrive in that order, not all at launch, and none of them exists yet.

The connectors are being designed for it, but I'm not promising a provider or a date. There's no working channel to request one yet. Contact: [VERIFIED MONITORED CONTACT PENDING]

Not at launch. GitHub is the only code host and CI.

Jira isn't in the launch set. Microsoft Teams is a stretch goal, not launch support.

RepoStaff plans to host the Management UI first. Agent compute rolls out separately: customer Linux/KVM hardware, then customer AWS, then gated RepoStaff-hosted AWS after the paid self-run launch. Hosted compute has no promised date.

Not at launch. Customer-run agent compute is a separate option. Full management self-hosting is demand-led, post-MVP work, with no date, easy setup, or support promised.

Anthropic and OpenAI API keys are the launch model options. Hermes is the planned Marshall runtime behind an adapter. OpenCode, then Claude Code headless, is the worker harness trial order. Harnesses are runtime tools, not model providers.

No. Subscription logins aren't a safe basis for a product like this. API keys only, and I don't resell model tokens.

Running agents on your hardware doesn't keep your code entirely on your network. Selected context goes to your model provider, and source may pass through the hosted control plane. Each worker will be one fresh VM for one ticket.

That isn't guaranteed. Launch customer scope is US-only, and primary hosting is intended to be in the US. Exact regions and data flows are unresolved, and neither is a promise that all data stays in the US.

To RepoStaff. By default you'll submit each key to an encrypted vault, and agents will reach your provider through a broker with a short-lived token for that job. Delivering a key directly into a job is off by default. Your provider still receives task and code context, so bringing your own key isn't a no-retention promise. None of this is built yet. [LINK TO SECURITY PAGE WHEN IT EXISTS]

The control plane: the Management UI and the integrations. Chat turns Marshall accepts and brain writes will pass through it, and source and prompts may too. The full data-flow write-up will be published before anyone connects a repo. [LINK TO SECURITY PAGE WHEN IT EXISTS]

No. It will work in DMs and in threads it's mentioned into. Discord and Slack will still send RepoStaff other channel events, and RepoStaff will discard those without storing them or passing them to Marshall.

That isn't set yet. Retention for the conversations Marshall accepts will be published with the data-flow write-up, before anyone connects a repo.

No, and it isn't in the first version. There's no penetration test or completed audit either. If you need those today, I'm not ready for you.

No. No open-source release is approved. Paying customers will receive source access and an issues and PR path, and the exact licensing and contribution agreements are deferred. The brain is your own repo, so that's yours regardless.

Flat per org, not per seat. The planned price is $299 a month for self-run and $699 a month for RepoStaff-hosted compute, plus your own model usage. See the pricing.

No. All prices and limits are untested hypotheses. Model-provider bills and self-run compute are separate, and no billing provider has been selected.

An inactive period shouldn't generate task-usage charges for compute you don't consume. The subscription or included plan continues, and so do persistent Marshall and shared infrastructure costs, including any customer AWS costs.

A $49 rate is planned for orgs of up to three members on their own hardware, with community help and no email support. It opens no sooner than 90 days after the paid launch, and only if the support load allows. Read the self-hoster conditions.

A planned $149 per org, per month for 12 months on self-run, or $349 on hosted compute once it exists. Billing begins after the first completed agent run on your repo. At most five teams. Read the proposed terms.

A verified, monitored contact hasn't been published yet, and nothing on this site collects your details. Contact: [VERIFIED MONITORED CONTACT PENDING]