Remote is a global payroll and employment platform based in Amsterdam. Its payroll business has surpassed $300 million in ARR, reportedly growing more than 300% year over year, while the company says it is cash-flow positive. Those figures should be checked against current financial disclosures. Remote earns this AI App of the Week designation for its 2026 product and operating changes, especially Remote MCP.
The short version: Remote shipped an MCP server that lets an AI agent use selected payroll tools through a controlled server, while more than 85% of its code was reportedly written by AI and revenue per employee rose 50% without AI-related layoffs.
What’s new in 2026:
- Remote MCP uses the Model Context Protocol, an open protocol that lets a client connect an agent to approved data and actions; payroll requires careful authorization because errors affect users’ pay and compliance
- BambooHR and Workday integrations can use Remote as a payroll engine through an API or other supported connections
- Remote reports more than 85% AI-written code, 60%+ higher engineering contributions, and hiring focused on upskilling
- Remote Build and Remote Labs help teams create tools on company infrastructure
- AI-powered payroll operates in more than 100 countries; confirm availability, documentation, and the latest product update before evaluating the service
1. Remote MCP: your AI agent can run payroll
The headline feature is Remote MCP, a remote mcp server built on the Model Context Protocol. In this model, an AI client connects to an mcp server, while the server exposes approved tools and data rather than an unrestricted account. Remote MCP servers can let an agent read workforce and compliance records, then submit specific requests when authorization allows. The available tools mcp supports should be confirmed in Remote’s documentation, along with the mcp server url, authentication method, and whether the product is generally available or still in preview. Remote servers may use streamable HTTP or SSE transport; the final connection method, headers, and mcp specification support require verification.
Authentication confirms the identity of the user or service. Authorization determines what that client and agent can do. A typical flow may use OAuth, an access token, and scoped tokens: the user starts the connection, the client sends a request, and the server checks permissions before returning data or executing a tool. Remote should document whether OAuth, an API connection, or another method is required, and whether an OAuth 2.1-style flow is used. A low-risk request might retrieve a payroll status or list approved records. A payroll change, payment action, or compliance update should require narrower authorization and explicit confirmation.
CEO Job van der Voort’s framing is blunt: connect ChatGPT or Claude and “you can control all of Remote,” to the point where “you don’t have to interact with our platform anymore.” That describes the agent-interface direction, not necessarily every capability available today. Users should verify the Remote MCP server name, supported tools, limitations, and audit controls before relying on the claim. Connecting MCP may eventually be as simple as clicking Add and entering a server URL, but local development, production access, and SSE transport can involve different setup steps.
Remote’s team demonstrates a practical use case: its Chief People Officer, who describes herself as non-technical, built a global case-management tracker with plain-English prompts connected to live workforce and compliance data through Remote MCP. The video should be checked against the claims, including whether the tracker used a production mcp server, which tools were enabled, and what confirmation safeguards applied. No engineering ticket or implementation cycle was required in the demonstration:
2. The CEO’s personal agent is the security model
Payroll data is highly sensitive, so Remote MCP’s central question is containment, not simply access. Van der Voort’s early experiment is his open-source personal agent, which he named Jim. Jim connects through the Model Context Protocol to an mcp server, but the exact capabilities of the remote mcp server and remote mcp servers should be confirmed in Remote’s documentation. A client’s authentication identifies the users and service making the connection; authorization then limits the agent, tools, and data it can use.
Van der Voort describes the setup this way: Jim can interact with Remote, “but he cannot do destructive things.” In a production design, that boundary should be enforced through scoped access tokens, explicit confirmation for high-risk actions, audit logs, and revocation. An OAuth 2.1 flow could send a token through approved HTTP headers, while the server checks each request before returning data or running a tool. Remote should clarify whether it supports OAuth, streamable HTTP, and the relevant MCP specification. A personal prototype does not establish enterprise readiness: the mcp servers must also isolate tenants, reject unexpected requests, and prove that the protocol prevents unauthorized changes.
3. More than 85% of the code is written by AI
Internally, Remote is among the more aggressive AI adopters among companies its size. Engineering contributions are reportedly up more than 60% over the last year, and van der Voort says that in the last month, “more than 85% of all of our code is written by AI.” Both figures need context: Remote should define whether “code written by AI” means generated lines, accepted pull requests, or code that was reviewed, tested, and deployed. It should also explain how it measures engineering contributions, the comparison period, and whether the results were independently audited.
Five Claude instances run on van der Voort’s second screen while he works, building projects for him and the company. The Slack agent that summarizes discussions began as one of those experiments. That workflow may show increased output, but AI-generated code is not automatically equivalent to productivity. Payroll-related code requires human review, security scanning, testing, compliance checks, and monitoring for incidents before deployment; Remote should also clarify whether Claude is used under an enterprise plan and whether customer data is excluded from training. The key value is safe, reliable software delivery—not a high percentage alone. Cloudflare Workers provides a useful infrastructure comparison only if the specific claim is verified; Cloudflare Workers should not be presented as evidence for Remote’s results. Remote’s $300M+ ARR and the reported metrics likewise require current documentation and clear definitions.
4. Revenue per employee is up 50%, with zero layoffs
The number van der Voort emphasizes is not ARR but revenue per employee, which Remote says rose 50% after AI adoption across every function, not only engineering. That figure needs a baseline, calculation method, employee count, and a clear definition of revenue versus ARR. Remote should also disclose whether the result reflects currency changes, acquisitions, contractors, timing, or changes in its workforce. The claim shows an association with AI adoption, not proof that AI alone caused the increase.
Remote says it has not cut jobs because of AI, unlike the Cloudflare comparison cited in the original account, where a reported 20% reduction accompanied efficiency gains. The immediate change appears to be hiring: departments planning to add headcount are asked whether they need more people or should invest in upskilling and AI tools instead. That is deferred hiring, not necessarily avoided work, and it still has employee consequences, including role changes, training costs, and increased review responsibilities for teams operating an MCP server. Remote should explain how its mcp server, mcp tools, client integrations, and remote servers affect staffing, rather than treating every productivity gain as an AI result.
In a broader AI operating model, a server may provide tools to a client, while multiple servers can support separate workflows; those technical changes do not by themselves establish business value. Van der Voort summarizes his role as ensuring that the company does not run out of money and grows quickly while tracking AI spending: “This adds a whole new fun angle, I would say.”
5. Remote Build: forward-deployed AI engineers
Remote says it is ahead of many customers on internal AI adoption, so it has productized that gap through Remote Build. The program places engineers with customers and prospects to design AI-powered payroll, compliance, and HR workflows. Before publication, Remote should clarify whether these are embedded employees, consultants, or implementation partners; how long each engagement lasts; what it costs; who owns the resulting workflow; and who maintains it after launch. Van der Voort calls the model “forward-deployed engineers,” a description often associated with Palantir.
A typical project could connect an mcp server to approved HR systems so a client can check onboarding status, send compliance reminders, reconcile payroll records, or request available data through controlled tools. That customer-specific automation is different from generally available MCP functionality: the server should isolate each customer’s data, limit the tools and integrations exposed, log requests, and require approval for sensitive actions. Remote should explain how its mcp server is tested, how multiple servers are separated, and whether customers receive production support after deployment.
Remote Labs, described as an internal marketplace where employees ship tools on company infrastructure, may supply ideas or components for Remote Build. The company should verify how Labs projects move from experiment to production, including security review, access controls, and ownership. Cloudflare Workers can illustrate a comparable deployment environment only if the comparison is documented; it should not imply that Remote uses Cloudflare Workers.
6. AI payroll is now live in more than 100 countries
The product underneath Remote’s AI strategy is still payroll, and its proposed moat is control of the underlying infrastructure. Remote says it owns and operates 100% of its legal entities instead of routing payroll through aggregators, and that its proprietary calculation engines now support payroll in more than 100 countries, with coverage expanding. This should be checked against the current country list: availability, local features, processing schedules, and compliance requirements may differ by country. “AI-powered” should also be defined clearly rather than treated as a substitute for documented calculation and review controls.
In an aggregator model, a company may depend on chains of local vendors, which can add handoffs, delays, errors, and compliance risk. Remote’s approach aims to keep local compliance logic closer to its own systems, but “processes instantly” should be qualified because payroll deadlines, approvals, banking rails, and country rules can affect timing. Its newer features reportedly include AI-powered employee surveys that analyze engagement in under a minute and AI-supported recruiting. If an agent accesses these systems through an mcp server, the server should expose only approved tools and data, preserve audit logs, and keep payroll actions separate from read-only requests. MCP access should complement, not weaken, local compliance controls.
Van der Voort’s description of the company’s scope is broad: “We do payroll for everybody, period.” Remote says it serves companies with office-based employees as well as distributed teams. That positioning should be evaluated by country coverage, employment model, implementation requirements, and the integrations available to each customer. A server or multiple servers can connect approved systems, but the architecture and customer-level isolation require documentation.
Zapier, the AI orchestration platform, is cited as one customer example. The company reportedly hired employees in 8 countries through Remote’s EOR during the last six months, reduced manual payroll data-entry time by about 80% after integrating BambooHR with Remote, and received compliance guidance in under 30 minutes instead of several hours. Remote and Zapier should confirm the dates, baseline, measurement method, scope of the integrations, and customer attribution before these results are presented as representative. Cloudflare Workers is unrelated to this customer example and should not be used as evidence for Remote’s payroll performance:
7. Where it fits and where it doesn’t
Remote fits companies hiring across borders that want payroll to become infrastructure rather than another dashboard. It may also suit teams ready for an agent to operate approved workflows through MCP. The best candidates have clear compliance ownership, supported country coverage, compatible integrations, technical staff for testing, and a risk tolerance appropriate for payroll. Before adoption, verify the Remote MCP server, the mcp server URL, available tools, customer isolation, and whether one server or multiple mcp servers are required. Confirm the client setup, authentication, authorization, and the users permitted to act.
MCP-based payroll access is new, so the evidence—not the protocol itself—should determine readiness. Start in local development or a sandbox with read-only tools, limited users, and a documented request flow. Confirm whether authentication uses OAuth, an access token, scoped tokens, HTTP headers, or another method. Review the mcp specification, streamable HTTP or SSE transport, and the steps to connect MCP; a production setup may involve clicking Add, entering the mcp server URL, and approving connections, while local development may differ. Test every tool mcp server exposes, log each request, and add approval gates before write actions. Remote should document enterprise audits and incident response. Deel, Rippling, and other competitors also claim AI payroll capabilities, so compare servers, tools, infrastructure, and controls—not feature lists alone. Cloudflare Workers may be a useful deployment comparison, but it is not evidence of Remote’s security or performance.
8. The “disappear in a good way” thesis
As agentic AI develops, Remote is betting that payroll software can “virtually disappear, in a good way.” Most vendors present an agent as a feature inside their platform. Remote is positioning its platform as a backend that an agent calls through an mcp server, with BambooHR and Workday as early evidence of that strategy. An MCP server is the connection layer that exposes approved tools and data to an agent; it is not the same as a conventional API, which may provide direct programmatic access without the same tool-discovery and context framework. Whether Remote can support reliable production workflows through one mcp server or multiple mcp servers remains a question for documentation and customer testing.
If Van der Voort is right, the strongest HR software companies may be those with dependable servers, accurate tools, owned legal entities, deep compliance expertise, and durable integrations—not simply the best dashboards. But infrastructure ownership is not an automatic moat. Remote’s thesis requires reliable mcp tools, strong authorization, clear audit trails, resilient servers, and customer trust when an agent handles sensitive payroll actions. Transport choices such as streamable HTTP may affect deployment, but they do not replace governance or human review. The reference to 50x multiples should be verified and placed in its specific market context; Cloudflare Workers is not comparable evidence unless the relevant claim is documented. Remote is a bet worth watching, but its success will depend on measurable reliability, security, and customer outcomes.
Remote MCP is a noteworthy test of whether the Model Context Protocol can move payroll from a dashboard into a controlled agent workflow. The value is not simply that an agent can send a request to a server. A production system needs reliable tools, clear authorization, strong authentication, durable integrations, and documentation that explains the client, server, users, permissions, and audit trail. Before adoption, teams should confirm the Remote MCP server name, mcp server URL, available tools, and whether Remote MCP servers are intended for production or evaluation.
Technical buyers should also verify the connection flow: whether the client uses OAuth 2.1, an access token, scoped tokens, HTTP headers, or another authentication method; how users approve authorization; and how the server handles failed requests or revokes access. The MCP specification, streamable HTTP, and SSE transport may affect deployment, while local development can require a different setup from production. Teams should test each tool mcp server exposes, compare the available tools mcp documentation with the actual product, and confirm whether “click Add” is sufficient to connect MCP or whether additional configuration is required. An API integration and an mcp server are related but not identical, and Cloudflare Workers provides a possible infrastructure reference—not evidence of Remote’s security or performance. Cloudflare Workers should not be presented as part of Remote’s architecture without verification.
About the Author
