Agents that do the work, not agents that demo well.
Most agent projects die between the prototype and production. We build the unglamorous parts, error handling, retries, escalation, logging, because that's the difference between a demo and something you can leave running.
The demo always works. That was never the hard part.
There's a well-worn arc to agent projects. A prototype works impressively in a week. Everyone is excited. Then it meets production, a rate limit, a malformed input, an API that returns success with an empty body, and it fails in ways nobody instrumented for. Trust evaporates faster than it was built, and the project quietly dies.
The intelligence layer is genuinely the easy part now. Frontier models are capable enough that reasoning is rarely the bottleneck. The bottleneck is integration, failure handling, permissions and observability, traditional software engineering problems that don't get attention because they're not the interesting part.
The second failure mode is scope. A general-purpose assistant that can theoretically do anything gets trusted with nothing, because nobody can predict what it will do. Narrow agents with explicit boundaries get used.
We're also willing to say when an agent is the wrong answer. A scheduled script or a well-placed webhook solves a lot of what gets pitched as agent work, at a fraction of the running cost and with far fewer ways to go wrong.
How it works, step by step.
Scope the agent narrowly
One job, explicit boundaries, defined inputs and outputs. Narrow agents get trusted and used; general ones get abandoned.
Connect to real systems
API or MCP integration into your inbox, CRM, database, storage and messaging. An agent not connected to anything is a chat window.
Set permissions at minimum viable
The narrowest access that lets it do the job. Anything irreversible sits behind explicit confirmation.
Build the failure paths
Retries with backoff, timeouts, malformed-input handling, and a defined behaviour for every failure mode we can enumerate.
Define escalation
When the agent is uncertain or out of scope, it routes to a named human with context, rather than guessing confidently.
Log every decision
Queryable months later. If someone asks why the agent did something in March, that's answerable rather than reconstructed.
Four things people assume this is.
A general-purpose assistant
Agents that can do anything get trusted with nothing. Ours have one job and explicit limits.
Autonomous decision-making
Irreversible actions, sending, paying, deleting, filing, sit behind human confirmation unless you explicitly decide otherwise, in writing.
A no-code workflow tool
Those are good products and sometimes the right answer. We'll tell you when one would serve you better than a custom build.
Always the right solution
A scheduled job or an integration solves plenty of what gets pitched as agent work, cheaper and with fewer failure modes.
Concretely, what's delivered.
- Narrowly scoped agents with explicit boundaries and defined behaviour
- Real integrations into your existing stack via API or MCP
- Minimum-viable permissions, least access that accomplishes the job
- Retry, backoff and timeout handling so transient failures don't become silent ones
- Escalation paths to named humans with full context
- Decision logging, queryable long after the fact
- Monitoring and alerting when an agent starts failing rather than after someone notices
- Honest scoping, including telling you when simpler automation is the better call
Why we can say this.
We build and operate agents across our own products, inbound qualification, outbound sequencing, content pipelines and document handling, and we use MCP where it fits alongside direct API integration where it doesn't.
The reason we're confident about the failure-handling emphasis is that we've had our own agents fail in production and had to fix them. That's a different kind of knowledge from having built one demo.
What this won't do.
- Agents are probabilistic. They will occasionally do something unexpected, which is why irreversible actions stay behind confirmation.
- They cost money per run. High-frequency, low-value tasks often don't justify model inference, and we'll do that arithmetic with you before building.
- They need maintenance. APIs change, models get deprecated, edge cases surface. An unmaintained agent degrades.
- They're not a fix for an undefined process. If nobody can describe the current workflow precisely, automating it just makes the confusion faster.
Straight answers.
How do you stop an agent doing something destructive?
Scope and approval gates. Agents get the narrowest permissions that let them do the job, and anything irreversible sits behind a human confirmation unless you explicitly decide otherwise in writing.
Do we need to move our data somewhere new?
No. We build around your existing systems. Migration is a separate decision and usually a bad one to bundle into an automation project.
What if we don't actually need an agent?
Then we'll say so on the first call. A scheduled job or a well-placed integration solves a lot of what gets pitched as agent work, at a fraction of the running cost.
How do you handle model deprecation?
We build against a provider-agnostic layer where it's practical, so swapping models is a configuration change rather than a rewrite. Complete portability isn't always achievable, and we're clear about where we've traded it away.
Can agents work with our internal tools?
If it has an API, yes. If it doesn't, sometimes via browser automation, though that's more brittle and we'd tell you so before relying on it.
Who maintains it afterwards?
Either us on a retainer, or your team with documentation and a handover. We're not trying to make you dependent.
Anqor is a small studio, so you deal with the person who builds it. If this isn't the right fit for your business, I'd rather say so on the first call than sell you something you don't need.
LinkedIn →Describe the workflow. We'll tell you if it needs an agent.
Half the time the honest answer is a scheduled script. That's a cheaper conversation to have before the build than after.