The AI-readiness layeron top of your HR systems.

Any HCM or HRIS, including Workday, SAP SuccessFactors, and Oracle HCM, plus the systems around them: payroll, time tracking, benefits, learning, and PEO platforms. Most enterprises run a mix that accumulated over years, several payroll providers plus a time system from a different era, and that mix is the normal case for us. Mapping it is one of the first things the 30-day analysis does. Every connection is governed and scoped per workflow to the data you agree we may read and write, which means an agent that coordinates leave has no path to compensation data it does not need. We ask for narrow access first and widen it only when a workflow needs it.

No. Your existing platform stays the system of record, and that is deliberate. Workday or SuccessFactors is good at holding the record; what it leaves to your team is the work around the record, which today lives in inboxes and spreadsheets. Oneward sits on top of your platform as the layer that does that work. An agent reads the leave balance from your HRIS, walks the employee through the request, collects the manager's approval, and writes the approved dates back where they belong. Your platform keeps doing what you bought it for, and if you ever replace it, the agents connect to the new system of record instead of becoming one more thing to migrate.

No migration. Agents work against your live tenant through a governed connection, scoped to the fields you agree we may read and write. Nothing is copied into a second system of record, and that closes off a familiar failure: a copy has to be synced, a sync eventually drifts, and then someone on your team owns reconciling two versions of the truth. It also makes starting fast, since connecting is a scoping exercise with your IT team rather than a data project. During a 30-day analysis the connection is read-only from the first day to the last.

Most HR landscapes include at least one, an older payroll engine or a portal your provider hosts, and the answer starts with mapping. During the 30-day analysis we map every system in scope and how each one can be reached, and reachability shows up in the plan as part of build effort. Where a clean interface does not exist, the plan says so and proposes a practical alternative rather than a workaround you have to maintain. Sometimes the honest alternative is that one step stays with a person while the agent carries everything around it; sometimes it changes which use case we recommend building first. What you will not get is a brittle integration that breaks on the next vendor update and quietly becomes your problem.

In the tools they already have open: Slack, Microsoft Teams, WhatsApp, or an embedded widget inside your internal portal. There is no separate app to roll out and no new login to forget, which is usually where new internal tools lose their users. An employee asks a question in Slack and gets an answer drawn from your own handbook, with the policy section cited, or updates bank details over WhatsApp, with a verification code required before the change goes through. The channel is a preference; what happens behind it is identical. Every request ends in the system of record, with the same approvals and the same audit trail regardless of where the conversation happened.

Yes. Approvals arrive as cards in Slack or Teams with the context already attached: what was requested, what the agent checked, and which policy it applied. A manager looking at a leave request sees the remaining balance and the proposed split of paid and unpaid days before deciding anything. One tap approves or declines, the decision writes straight back to the system of record, and the log entry carries the approver's name, reversible where the underlying system allows. Who approves what is defined by your own policy; we configure the approval chains you already have instead of inventing new ones. An action set to require approval waits until it gets one, because the write does not happen without it.

The base set covers policy and benefits questions, leave and absence requests, personal data updates, document requests, and status checks on anything in flight. In practice it is more specific than that list sounds. An employee asking what parental leave allows gets the answer from your own handbook, with the section cited. Leave requests that overrun the remaining balance come back as a proposed split of paid and unpaid days, checked against policy before any dates are written. A bank-account change requires a verification code, and an employment-verification letter for a visa or a rental is generated from verified employment data. Each workflow you bring into scope adds its own request types, so the honest answer is that the list keeps growing as you deploy more agents.

It hands over to a named person with the full context, and tells the employee it did so. Full context means the conversation so far, the data the agent checked, and the exact point where it stopped, which spares the employee from explaining everything twice. Handover is the designed behavior for anything the agent should not decide, like a sensitive employee-relations matter or a case the policies it was built on never covered. Which situations escalate, and to whom, is configured with your HR team during deployment and adjusted as experience shows what the agent handles well. The failure mode we build against is the silent dead end, where a request disappears and nobody owns it.

Most of the HR process that runs off-platform, in the inboxes, spreadsheets, and follow-ups around your HRIS, can be automated with AI: onboarding, leave, role changes, reorganizations, performance cycles, offboarding, and keeping data aligned across systems in between. Chasing interviewers for overdue scorecards, mapping a parental leave split by hand against local law, rebuilding a reorg upload file that failed on broken reporting lines, checking a pay run before the money moves: none of that lives in the HRIS, and all of it can be carried by an agent. The practical test is simple: any HR task that follows rules and touches your systems can be a use case. What stays with people is judgment, the sensitive conversation and the exception no policy anticipated. See the use cases above for examples.

Each agent is built during deployment, with your team, around three things: your policies, which become the source of its answers, cited by section; your approval chains, which decide who says yes before anything is written; and your systems, the ones it actually reads and updates. Our engineers do that setup alongside your HR and IT teams until the agent runs reliably and you approve it, and nothing changes in production before you sign off. When a policy changes or a system is swapped out, the agent is updated to match. Nothing is shipped as a generic template you have to adapt yourself, because a template that is almost right about your leave policy is wrong about your leave policy.

You choose which models are allowed, and that decision stays with your security team. Typical allowlists include OpenAI, Anthropic, Google Vertex AI, or self-hosted open models where you require them, and agents call only the endpoints on your list, private endpoints included. Everything past that line is our job. Model quality varies by task; the model that drafts a good reference letter is rarely the one you want checking a pay run, which is why we evaluate, tune, and monitor models per workflow against your real cases. When a model on your allowlist stops being the right choice for a workflow, we make the change, inside the same rules. Your team sets the boundary once and never has to become a model operations team.

We do, together with your team, for an agreed period that is written into the contract. Agents run against policies and systems that keep changing, and an agent that was correct in March can be quietly wrong by June, which is exactly what maintenance exists to catch. During the engagement we ensure the agents keep working as expected: we monitor each workflow, update agents when your policies change, rebuild connections when you replace a system, and take on new use cases as they come up. Your team stays involved throughout, since the people who know a policy shifted before it reaches any document are yours.

Agents run in your cloud or in ours, with scoped, least-privilege service accounts either way. Where they run is a decision your security team makes during the review, and the controls do not loosen with the choice. In your cloud, agents operate under the network and identity controls you already enforce, and your team watches them the way it watches any other workload. In ours, each customer is separated at the tenant level, and a service account is scoped to the workflows you approved with no broader reach into your systems. Your data does not mix with anyone else's, and it never leaves your boundary of trust. Whichever way you decide, an agent holds the minimum permissions its workflows need, against only the data you agreed we may read and write.

Permissions follow the workflow: each agent operates with the minimum access that workflow needs, agreed when it is scoped. Any action that changes a record, a payment, or an entitlement can be set to require a named human approval, delivered in the tools your managers already use, and who approves what is defined by your policy. On the audit side, every action an agent takes is logged with what it read, what it did, and who approved it. Entries are attributable, reversible where the underlying system allows, and exportable to your own tooling, so your security team reviews agent activity in the same place it reviews everything else. Retention is agreed per customer, with a default of 90 days.

Under NDA, and before anything is connected. We work through your security questionnaires and hold architecture calls with your team, at whatever depth your security and IT people want: where agents run, how data flows, what is redacted before anything reaches a model, how service accounts are scoped, and how approvals and logging are enforced. Expect straight answers on limits as well; where something is a constraint, we describe it as a constraint instead of talking around it. The review runs at your pace, and nothing touches your systems until your team is satisfied. Write to partners@oneward.com to start.

Week one we sign the NDA and, if you need one, a data processing agreement; you choose up to three use cases and we agree which data we may read. From day 8 to day 21 we read the agreed data and count how often each use case comes up, then check what is possible, what it costs to build, and what it returns. Week four we write the plan, and you have it on day 30. Throughout, access is read-only and we change nothing in your systems. Your side is light: one named contact, a 30-minute check-in each week, about one to two hours of your team's time each week. The counting matters, because the use case that feels urgent and the one your data shows is frequent are often not the same, and the plan follows the data.

Nothing. The analysis is free, covering all 30 days of work and the written plan you keep; the only real cost is about one to two hours of your team's time per week. If you decide to build, we send a written offer for exactly the scope in the plan, which means the offer can be checked line by line against a document you already own. The plan is complete on day 30 whether or not you ever ask for the offer.

A written plan for each use case you chose, built from your data and your process during the 30 days. Every plan covers the same eight items: what the agent does, as exact steps in plain language; which systems it reads and which it updates; cases per month, counted from your data; time saved per month, measured against your current process; build effort in weeks, including what we need from your team; risks and controls, down to what stays read-only and who approves each write; the return, and when the saving starts; and a recommendation on what to build first and why. It is written to be handed to a CFO or to another partner as it stands. If the numbers do not justify building a use case, the plan says that too.

You keep the plan. Use it internally, or build it with another partner; it is yours to hand over, and specific enough to build from, with the steps and systems for each use case written out. Everything we read during the analysis is deleted after day 30 and our access ends with it, which makes walking away clean. There is no obligation. A plan that tells you not to build yet is still a useful plan, and some plans will say that.