Click anywhere to close
Two ways in. Practitioners work by assignment and are the knowledge behind every worker. Staff build and run the company, and there will never be many of them. Both are listed here when open.
Specialists from any desk on the roster, engaged by assignment, hours on a ledger, a quality record that is yours.
Postings are English documents. Each says what the role owns, what it needs, and who it reports to.
You build and own the layer between a worker and a client's systems: the adapters that read and write SAP, Oracle, NetSuite, Dynamics and the rest, and the execution discipline that makes every write idempotent, verified and audited. It is the part of the platform a client's security review opens first and a bank's auditor reads last.
A Humetry worker does not advise; it acts. It parks an invoice, releases a payment proposal, posts a receipt, creates a credit memo request, in the client's own ERP, under an identity the client's administrators provisioned. Every one of those writes has to be safe to repeat, provable after the fact, and impossible outside the scope the client delegated. That layer does not yet exist in the form it needs to. You will build it, and for a while you will be it.
The work is unglamorous in the way that matters. An idempotency key or a transaction identifier where the system allows one, and a documented substitute where it does not. A status check after every timeout and before any retry, because a write that timed out may have landed. The resulting document re-read from the system and recorded, so the record says what the system says and not what we hoped. One adapter interface, one adapter at a time, each built against the vendor's sandbox before any client is in sight, each carrying the same guarantees. The first is SAP; the order after that follows the first engagements.
You will sit in client security reviews and answer for the integration identity, its scopes, its secrets and its audit lines. You will be on the call when a write is ambiguous at two in the morning in the client's time zone, and you will write the incident record a controller can read. You report to the founder, work beside the engagement owner and the practitioners, and are the engineering department for as long as it takes to earn a second engineer. Success looks like this: a client's auditor reads the trail of a case without us in the room, and finds nothing to ask.
The engineer who builds the worker itself: the runtime that takes a desk's procedures, the client's authority rules and the lessons learned, puts a model to work over them, and lets it act only through the platform's checks. The scientist decides what a worker knows; you build the machine that runs it, case after case, all day.
Between a model and a client's ERP stands the worker runtime: the loop that picks up a case, reads the evidence, follows the desk's procedure, decides, asks the platform whether it may act, acts through an adapter, re-reads the result and writes the record. It has to run thousands of cases a day across twenty-three desks, stop cleanly when it must, escalate when no rule resolves a case, and leave a trail a controller can read. It does not exist yet. You will build it, and you will be the one who knows why it did what it did.
The work is the discipline of a system that acts. A procedure engine that follows written procedures faithfully and surfaces where they are silent. A tool layer that exposes an adapter's reads and writes to the model only within the identity's scopes. An authority check that runs before every write and cannot be reasoned around. A case state machine in which a case waiting on someone is open and never complete. A record writer that chains every entry. Cost and latency you can predict per case, and a harness that replays any case from its record. You will choose the model interface so that a desk's model can be swapped when the researcher's measurements say so.
You will work with the founding engineer who owns the adapters, the scientist who decides what a worker learns, the researcher who measures it and the expert who attacks it. You report to the founder. Success looks like this: the first worker runs accounts payable against a vendor sandbox end to end, every case it closed can be replayed from its record, and the second desk takes a week, not a quarter.
The scientist who decides how a worker is taught: how a practitioner's correction becomes a scoped, versioned, tested lesson, how a desk's procedures are represented so a model follows them and a controller can read them, and which model runs which desk. You own the method by which the workforce gets better without ever learning a transaction right.
A Humetry worker is not a prompt. It is a desk's procedures, the client's authority rules, the lessons learned on that engagement, and a model that reasons over them, held inside a platform that decides what it may do. The quality of the first three is the company's moat, and the method for building them does not yet exist in a form that scales from one desk to twenty-three. You will build that method.
The central problem is scope. When a worker was wrong about one supplier's unit of measure, the correction must become a lesson about that supplier, for that client, in those dates, and never a rule for every supplier. You will design how lessons are represented, bounded, versioned, tested on cases the worker has never seen and on the cases it already got right, deployed, and watched; and how procedures are written so that a model follows them faithfully and a controller can read what the worker will do. You will decide, desk by desk, which model runs it and how that choice is measured, and you will change your mind when the measurement says so.
You will work with the practitioners who approve lessons, the researcher who measures the workers, and the engineers who run them. You report to the founder. Success looks like this: a desk that has run for a quarter is better than it was, every improvement can be traced to a correction a named practitioner made, and nothing the worker learned ever widened its authority.
The researcher who measures the workers: the historical evaluation before a pilot, the gates during it, the scorecard every week after, and the drift nobody noticed. You decide what complete means in numbers, and you are the reason a client can trust them.
Every engagement passes four gates, each a threshold the worker must clear on cases it has never seen, judged by severity. Every week after that, a scorecard reads five measures against their thresholds, and the renewal decision in week sixteen rests on them. Those numbers are worth exactly what the method behind them is worth. You will own the method.
You will design how historical cases are sampled, held back and marked with the practitioners; how accuracy is read by severity rather than by count; how autonomous completion is measured so that a case waiting on a person is never counted complete; how a worker's reading drifts over weeks and how that drift is caught before a client catches it. You will study failures the way a safety engineer does: by class, by cause, by what the record shows the worker read before it acted. You will publish the method to clients in plain words, because a measure nobody can read is not a measure.
You will work with the scientist who teaches the workers, the engagement owners who present your scorecards, and the practitioners who mark the cases. You report to the founder. Success looks like this: a client's controller reads the week's scorecard, understands every number on it, and finds that it matches what their own people saw.
The person who attacks the workers before anyone else does: instructions hidden in invoices and emails, authority boundaries, the write protocol under failure, the walls between client environments. You own the adversarial side of the control page, and the evidence a security review asks for.
A Humetry worker reads documents all day: invoices, remittances, emails, portal messages. Every one is a channel through which someone might try to tell the worker what to do. The platform's rule is that documents are evidence, not instructions, and that a worker holds exactly the authority the client delegated. A rule is only as good as the attacks it has survived. You will run the attacks.
You will build the adversarial case sets: injected instructions in every form a supplier or customer could send, attempts to reach a reserved action through a permitted one, writes that time out at the worst moment, two sources that disagree in ways designed to mislead, and the cross-client probes that must find nothing. You will run them against every desk before it enters a client environment and again at every release, in vendor sandboxes first. You will write the findings into the control description a client's security review reads, and you will sit in that review.
You will work with the engineer who owns identity and the write protocol, the scientist who owns what a worker learns, and the researcher who measures it. You report to the founder. Success looks like this: an attack that would have moved money is caught in a sandbox, written up, turned into a regression case, and never seen in production.
The one named person a client holds accountable for the service: the scope, the thresholds by severity, the four stages and their gates, the decisions inbox, the weekly report, the incidents, and the conversation when something is wrong. You have run a finance tower or audited one, and you can tell a reasonable answer from a correct one.
Every Humetry engagement has one accountable owner, with a named backup and a documented handover. The owner is not a project manager and not an account manager. The owner is the person who agreed with the client's process owner what complete means, case by case and severity by severity, and who answers for whether the workers met it this week.
The engagement runs in four stages, historical evaluation, shadow operation, supervised production, recurring service, each with a gate and a threshold the worker must clear on cases it has never seen. You run discovery and process mapping, write the service description and the acceptance thresholds, and present the scorecard at each gate. You read the weekly report before the client does. You classify every intervention honestly: a capability failure goes to engineering, a policy gap goes back to the client's owner, a data problem is named as one. You never let a case that is waiting on someone be called complete.
When a client corrects a worker, you turn the correction into a proposed lesson with an explicit scope, because a rule for one supplier must never become a rule for every supplier, and you put it in front of the practitioners who approve it. When something goes wrong, you own it until it is resolved and you say so in writing. You report to the founder. The first engagement is run with the founder beside you; the second is yours.
A practitioner assignment, not a staff role. You are the human judgment behind a worker's exceptions and the historical cases it is evaluated on: you decide, you write the reason every time, and your corrections become tested lessons. Hours on a ledger, a quality record that is yours.
A worker on an accounts payable, cash application or deductions desk escalates the cases no rule resolves: a supplier asserting an agreement not on record, a deduction without a reason, two sources that disagree. Those cases come to you. You decide them against the client's policy and the contract, you record the reason in words a controller would accept, and you close them. Before a pilot, you mark the held-back cases the worker will be scored on, by outcome and by severity, so the thresholds mean something.
The scope of a correction is yours to set. When a worker was wrong about one supplier's unit of measure, the lesson is about that supplier, that client, those dates, and you narrow any proposal that reaches further. You approve lessons, narrow them, or send them back, and the platform tests each one on cases it has never seen before it is deployed.
This is engagement work with the scope, the rate and the dates written down before you start. Your hours and accepted work are on a ledger you can read at any time, paid on the agreed cycle under the practitioner standard, and every piece is reviewed, so your standing and your quality record travel with you from assignment to assignment. Engagement terms and worker classification follow the arrangement and your location. You qualify in your tower first; the qualification is the only unpaid work.