Build an AI workflow

Give an AI assistant real HR work (onboarding a batch of new hires, tidying the org chart, answering "who reports to whom") while HR stays in control. The assistant does the busywork; people decide.

1. Connect the assistant#

The simplest way is signing in: paste https://<company>.bizisy.com/mcp/manage into Claude, ChatGPT, Cursor or another MCP client, sign in to Bizisy and press Allow (Connect an AI app). The assistant then works as you, with your role.

For your own agent (a scheduled job, a bot in your chat tool), use a Manage API key on https://api.bizisy.com/mcp/manage, created from a login whose role fits the job.

2. Let it read the skills#

The server's instructions point assistants to skills, procedures for common work: skill://platform/first-session when it starts, skill://org/setup-company, skill://org/manage-people, and others. They tell it to read before writing, preview every change, show the person and commit only after they agree. You don't need to repeat that in your prompt.

3. Give it a procedure of your own#

Describe the work in plain steps, with the checks you'd make. For example, a weekly onboarding run:

Every Monday:
1. List people starting in the next 14 days (org_people_list with status "pre_hire").
2. For each one without a login, preview an invite (org_invites_create with dry_run).
3. Show me the list and the previews. After I say yes, send the invites.
4. List open onboarding checklists (org_checklists_runs_list) and tell me which tasks are overdue and who owns them.

4. Review in Bizisy#

Every result carries a view_url: the preview or change in Activity. Each preview and each change the assistant makes, and each failed attempt, is recorded there with the app's name. Approvals still apply: a job change that needs approval becomes a request for the approver, whoever proposed it (Previews and approvals through AI).

What the assistant can't do#

It is a machine: no one else's private details or pay, no approving or rejecting, no pay changes, no new webhook endpoints, no new keys. Those need a person in the web app, by design.

Building with your own model#

If you write the agent loop yourself, the MCP tool list is your function catalogue: each tool's description says what it does, who may call it and its limits, and its input schema is the action's. Call writes with dry_run: true first, and keep a person in the loop for the commit.