Agents, and the parts of your work a model shouldn't touch
Most of what gets sold as AI right now is a demo with an invoice attached. I work the other direction. Before I write anything, I sit with the actual workflow: who touches it, what they retype, where it stalls, and which of those steps a model or a scheduled job could carry without someone checking its homework every time. Sometimes the answer is a narrow agent running on your accounts. Other times it's a setting in software you're already paying for, and I'd rather point at that and lose the build.
What the work actually is
Six things worth saying plainly before anyone signs anything.
Where a model fits, and where a person stays
An agent is good at the parts of a job that are legible. Pulling the same four fields out of the same form. Checking one system against another and flagging what moved. Drafting the boring first version of a document that a person then fixes. It's much worse at the parts where being wrong is expensive and nobody would notice for a month. So the real design question is where the check goes and what the reviewer actually sees when they get there. Approvals, anything that moves money, anything that grants access, anything a customer or an auditor would ask you to explain later: a person stays on those, and I'll put that in the design in plain language instead of burying it in a diagram.
Harness design means permissions, context, failure, and checkpoints
A working agent is mostly boundaries. Which tools it can call and under whose credentials, and whether those credentials are scoped down to the one mailbox or the one folder it actually needs rather than whatever was easiest to wire up. What it's allowed to see, how much of the prior conversation it carries forward, and what gets stripped before anything leaves your tenant. What happens when a step fails: does it retry, does it stop cold, does it leave a half-written record behind, and does a person get told. Where the human checkpoints sit, and what they look like from the side of the person doing the checking. I run an agentic harness and a homelab of my own, and that's where I've learned most of this and where I test before anything goes near a client system. That's bench experience. I'm not going to dress it up as a production track record.
Bridges between systems that were never meant to talk
A lot of what arrives labelled as an AI problem turns out to be a plumbing problem. Two systems each hold half the answer, no vendor has bothered to connect them, and so somebody exports a CSV every Tuesday and pastes it somewhere. That's the shape of work I've built against before. One example: a user access review system that pulls application access out of Active Directory, compares it month to month, and checks the Jira ticket numbers attached to authorization changes so each difference has something to point at. Another: a PowerShell and PowerCLI workflow that calls Cohesity APIs to restore virtual machines, brings the restored VMs up programmatically, and runs monthly PowerShell checks of backup restorability. Neither of those is an AI system. They're the scaffolding that has to exist before an agent has anything steady to stand on, and fairly often they're the whole answer on their own.
Four options get weighed, and custom has to win out loud
Before I build anything, four options go on the table together. Change the process, because sometimes the step everyone hates exists for a reason nobody at the company remembers. Use a native capability in software you're already licensed for, which is the answer more often than the people selling you new software would like. Use an existing connector, which is boring and supported and maintained by somebody who isn't me. Or build something narrow and custom. Custom only wins if I can say plainly, to your face and before any money moves, why it beats the other three on reliability or on operational value. If I can't make that argument in a sentence you'd repeat to your boss, you shouldn't pay me to build it.
The first engagement is small, paid, and ends on paper
Nobody should hand a solo shop a build budget off the back of a sales call. So the first piece of work with a new client is a bounded engagement. It's paid, it's priced to be an easy yes rather than a committee decision, and it produces two written things: a map of how the workflow actually runs today, including the manual steps people stopped mentioning years ago, and a candid read on which parts an agent or an automated job would genuinely help with. Sometimes that read comes back saying most of it. Other times it says one piece is worth automating and the rest should stay human, and that's a real finding, not a failed sale. For clients in Atlanta and Marietta I'll come sit with the work in person, because watching someone do the job for an hour beats any questionnaire I could send you. Remote clients elsewhere, that hour happens over a screen share, and honestly it works nearly as well.
What I haven't done yet
There's no Chrysis AI product. Nothing hosted, no platform with my name on the login screen. And I haven't shipped an AI deployment for a client yet, which is normally the part a page like this hides behind a wall of logos. Here's the honest state of it: the hands-on capability is real, and the client deployment isn't there yet. Everything I build runs inside your environment, on your accounts, under your credentials. The code is yours. If you stop working with me, nothing switches off and there's no key I'm still holding. You should know all of that before the first invoice rather than after it.
Start with the map
A paid, bounded first engagement. You get a written picture of how the work runs today and a straight read on which parts an agent or an automated job would actually earn. If the answer turns out to be that you don't need me to build anything, that goes in the writeup too.
Send me the one workflow that's eating the most hands-on time right now, and I'll tell you whether it's worth a closer look.