Engineering and AI

Business Automation

Internal workflows, integrations and approval pipelines automated with a person in the loop where it matters, least-privilege access, an audit trail and a way to stop every run.

An automation is a colleague with no judgement and standing access. It runs when nobody is watching, acts on whatever arrives in the inbox or the webhook, and repeats a mistake faster than anyone can notice. Many are also built on one person's account with an admin token and no record of changes, so when that person leaves, nobody can say what it does or what it can reach.

We map the process as it actually runs, including the exceptions people handle from memory, before choosing what to automate. Each automation runs under its own service identity with only the access it needs, logs every action, and has a stop switch. Approvals and judgement calls stay with a named person. Where an LLM helps, for example reading an invoice or triaging a request, its output is checked before anything acts on it.

Usually, one of these is true

Finance, operations or support staff re-key the same data between systems every day, and the errors only surface at month end.
A workflow the business depends on lives in one person's automation account, running on an admin token nobody has rotated.
Approvals for refunds, payouts, discounts or access requests happen in chat threads, with no record an auditor would accept.
You want an LLM to read documents or triage requests, but not to move money or change records without a person signing off.

What we automate

Processes that cross systems and teams. For each one we decide what runs unattended, what waits for a person, and what happens when a step fails.

Process mapping. The workflow as it really runs, including exceptions, workarounds and who decides what, drawn up with the people who do the work before anything is automated.
Integrations. Connections between CRM, ERP, finance, HR, ticketing and internal databases through APIs and webhooks, with explicit field mappings, idempotent writes and retries that never duplicate.
Approval pipelines. Multi-step approvals with thresholds, delegation and segregation of duties, so the person who requests a payout or an access change cannot also approve it.
Human in the loop. Review queues for low-confidence or high-value cases, a handover to a person with the context attached, and escalation when nobody acts.
LLM-assisted steps. Extraction, classification and drafting with structured outputs, rule checks, confidence thresholds and a non-LLM fallback, with the model given no authority to act alone.
Access, audit and failure. A service identity per automation, scoped credentials in a secrets store, an append-only log of every action, alerting, dead-letter handling and a stop switch.

How the build runs

We scope it with you in the chat, then send a written scope with a fixed price and fixed dates. We automate in stages, and each stage runs alongside the manual process before it replaces it.

Process mapping. We sit with the people who run the process, record every step, system, exception and decision, and agree which steps are automated, which stay manual and which need an approval.
Access and failure. Before building, we define the service identities and their scopes, the audit log, what each step does when it fails, and how a run is paused or reversed.
Build in stages. Each stage is built where it fits best, in a workflow tool you already license or as a small service in your own stack, and tested against the real edge cases from the mapping.
Parallel run. The automation runs next to the manual process on real inputs until the owners are satisfied with the results. Before switch-over, the team that runs our penetration tests checks the integrations, webhooks and credentials.
Handover. We hand the runbooks, process maps, credentials inventory and alert routing to the owner of each workflow, and remove our own access.

What you get

Process maps. Current and automated versions of each workflow, with every decision point and owner marked, for operations leads and auditors.
Working automations. Workflows and integrations running in your accounts under service identities you control, never on a personal login or on ours.
Audit trail. A log of every automated action, input and approval, kept where you choose, that answers who did what and when.
Failure and stop procedures. For each automation: what alerts on failure, who receives it, how to pause it and how to reverse what it did.
Credentials inventory. Every token and service account the automations use, with its scope, its owner and how to rotate it.

What we need from you

A process owner for each workflow who can decide what should happen in the exceptions.
Time with the people who do the work today, and real cases to test against, including the awkward ones.
Admin or API access to the systems involved, with sandbox or test environments where they exist.
Your approval rules and limits: who may approve what, and which actions always need a person.
Your data handling constraints, especially for anything that would be sent to an LLM provider.

What we can show you

Tested before it runs. Integrations, webhooks and credentials go through a security test pass by the team that runs our penetration tests, with each finding reproduced and rated with CVSS v4.0 before go-live.
Nothing tied to us. Automations run in your accounts under identities you own, each with a runbook. There is no platform of ours in the middle and nothing to renew with us.
Built for the audit. Approval steps, segregation of duties and the action log are designed to give a SOC 2 or ISO 27001 assessor the evidence they ask for. We do not certify; we work alongside whoever signs off.
Sensitive processes handled quietly. Mutual NDA and PGP before we see a process that touches payroll, customer or financial data. Access stays limited to the engineers doing the work, and client names stay undisclosed.

Standards we work to

The protocols and control frameworks these automations are designed against, so access is delegated properly and approvals stand up in an audit.

BPMN 2.0
OAuth 2.0
OpenID Connect
OWASP API Security Top 10
OWASP Top 10 for LLM Applications
AICPA Trust Services Criteria

Common questions

Which automation tools do you use?

We start with what you already pay for and your team already knows. Where a workflow tool fits, for example Zapier, Make, n8n, Workato or Power Automate, we build in it. Where the logic, volume or data sensitivity outgrows one, we write a small service in your own stack, and the recommendation comes in writing with the reasons.

Who owns the automations?

You do. They run in your accounts under service identities you control, with credentials in your secrets store and documentation for each one. Nothing runs on a personal login or on infrastructure of ours.

Where does an LLM belong in a workflow, and where not?

It is good at reading messy input: pulling fields from invoices, classifying requests, drafting a reply. It should not decide on its own to pay, refund, grant access or delete. We check its output against rules, send low-confidence cases to a person, and keep a non-LLM fallback for when the model is unavailable.

What happens when an automation fails?

It stops and says so. Each automation alerts a named owner, holds the failed item for retry or manual handling, and never retries a payment or record change in a way that could duplicate it. Every run can be paused, and the log shows what it did so it can be reversed.

Who maintains it when a connected system changes?

Your team, using the runbooks and the credentials inventory. Vendors rename fields, retire endpoints and expire tokens, so each automation's dependencies are listed with where to check. If you would rather we keep an eye on it, we scope that separately.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.