AI agents that get work done, inside your guardrails.
AI agent development services for real work: software that pursues a goal you set, works inside the systems you allow, and stops for human approval before anything irreversible. Every step logged.
Reply within four business hours (typical) · Guardrails, not guesswork
In one answer
PixelCrayons builds AI agents: software that carries out a multi-step task inside your systems and stops for a person before doing anything it can't undo. An agent plans its own steps: look up the order, check stock, draft the reply, then wait for sign-off before sending. Each tool it can touch is permissioned and each step is logged. It suits repeatable work that needs judgement between steps; a fixed sequence is better built as a plain workflow. Pilots run direct or white-label.
Discovery starts by asking whether the request is actually agent-shaped: multiple steps, several tools or systems involved, a path that genuinely varies with what it finds along the way. A lot of what gets pitched as "an agent" is really a single grounded answer or one fixed sequence. Those are better served by a chatbot or a workflow build, faster and with less to guard. If your request is one of those, the discovery document says so.
Week zero
02
A goal and the tools to reach it
The agent is given a goal and a defined set of tools it can call (a CRM lookup, a search, an API, a database read). It plans its own sequence of steps toward that goal, holding the relevant context across the run rather than starting cold each time. Every call it makes, and why, is part of the record. That planning loop is the actual engineering; a demo that just chains three prompts together isn't the same thing.
Architecture
03
Guardrails: scoped permissions and approval gates
This is not a fully autonomous black box. Each tool call carries only the access that specific step needs, never a blanket key to your stack. Anything irreversible, externally visible or above a threshold you set (a send, a spend, a write to a live system) waits for a person before it executes. The agent proposes the action and its reasoning; a human decides whether it happens. Judgement on consequential decisions stays yours.
Every build
04
Evaluated before it runs unattended
Before an agent is trusted with a real task alone, it runs supervised against scenarios drawn from the actual job, including the ones where the obvious next step is the wrong one. Its accuracy is then measured against your own baseline, not a vendor benchmark. The evaluation suite re-runs whenever the tools or the data it depends on change, because a guardrail tuned for last quarter's system isn't a guardrail for this quarter's.
Before launch
05
Handover, logs and ownership
Every run leaves an audit trail: what the agent was asked to do, what it called, what it decided, and what a person approved or changed. At handover you get the runbook and admin training, under IP and ownership terms agreed before work starts: how to adjust the permission scope, add a tool, read the logs, or switch the agent off. A light retainer is the usual shape after launch, for monitoring and the changes the first month teaches; running it entirely in-house is fine too.
At handover
The pilot
From a scoped goal to a working agent.
01
Days 1 to 3
Discovery & scope audit
We map the task, check it's genuinely agent-shaped rather than a workflow or a chatbot in disguise, and agree in writing the tools it can call, the boundaries it can't cross, and where the approval gates sit.
02
Week 1
Pilot scoped & priced
A written scope lands: the goal, the systems and tools it touches, the permission boundaries, the approval rules and a demo date. You approve the itemised price before anything is built.
03
Pilot
Working agent, one real task
The agent works a real task from your operation, supervised, every step logged, checkpoints firing exactly where they were designed to.
04
Weeks 3 to 6
Evaluate, harden, hand over
Supervised runs earn their way to unattended operation only where the measured accuracy supports it. Permissions get tightened where the evidence says so, your team learns the runbook, and we say so plainly if a step should stay supervised for good.
Inside Prism
Your engagement, week to week, in one workspace.
Where the engagement includes it, your AI build runs in a Prism workspace you log into: requests, approvals, the task list and the weekly review, with each decision and its expected result written down.
An agent that plans its own steps still needs a boundary on what those steps are allowed to touch. This is the loop every run follows (planning, a tool call, a guardrail check) and exactly where a person is built back in.
The run
01
Goal & scope
The agent receives a defined objective and the boundary of what it's allowed to touch: specific tools, specific systems, nothing implicit.
No decision here
Nothing executes yet. A goal with open-ended access is the wrong design point, so the goal and the permission scope are agreed together, in writing, before the agent runs.
02
Plan
The agent breaks the goal into steps and decides, at each point, what it needs to know or do next: read a record, call an API, ask a question.
Ambiguous or missing information
The agent asks rather than assumes. A plan built on a guess compounds with every step that follows it, so an underspecified step pauses for input instead of inventing an answer.
03
Tool call
It calls the specific function or system the step requires (a lookup, a search, a database read), using credentials scoped to only what that call needs.
Tool fails or returns nothing useful
Logged and retried on defined rules, or handed to a human. The agent doesn't fabricate a result to keep the run moving. That's the single most common way an agent quietly produces nonsense.
04
Guardrail check
Before anything irreversible or externally visible happens, the proposed action is checked against the permission scope and the approval rules agreed upfront.
Above the approval threshold, or outside scope
Held for a human sign-off before it executes, not after. Sending something, spending money, writing to a live system: these thresholds are set by you, not inferred by the agent.
05
Act & log
The approved action executes, the step and its reasoning are written to an audit trail, and the agent checks whether the goal is met or another step is needed.
Downstream system rejects the write
Rolled back to the last clean state and raised. That's the same discipline as our automation builds. A half-finished action left unresolved is worse than a run that simply stalls.
Where a human is built in
The rule the whole loop is built around: an agent that stops and asks costs you a few minutes. One that acts past its permissions costs you the audit.
Illustrative run: a generic multi-step task, not client configuration
How we report it, in Prism
The eval scorecard, before the pilot goes near a customer.
What you receive in month one
AI work is reported against an evaluation set built before any model is chosen. In the first month you receive the task definition with the inputs and acceptable outputs written down, the eval set of real cases with expected answers, and the scorecard showing accuracy, refusal behaviour and cost per run. The go/no-go checklist names what must hold before the pilot touches live traffic.
01Task definition: inputs, acceptable outputs, and the cases the system must decline
02Eval set: real cases with expected answers, reviewed by your team
03Scorecard: accuracy, refusal behaviour, latency and cost per run
04Go/no-go checklist: the thresholds the pilot must meet before launch
05Failure log: each wrong answer, its cause, and the fix applied
Fixed path, run at volume: that is workflow automation. One question, one grounded answer: that is a chatbot. Not sure which you need? Discovery says which, in writing, before anything is priced.
Each one says where it applies and links to its full terms.
Response and start times
We typically respond within four business hours. Eligible engagements can typically start within two to three business days after scope, payment and required access are confirmed.
Business hours are Monday to Friday, 9:00 am to 6:00 pm IST, excluding published company holidays. Typical expectations, not guaranteed service levels.
Every delivery is reviewed before release by QA, your Project or Account Manager and a senior delivery lead, and you then review it against the acceptance criteria agreed at the start. Our specialists use AI to support delivery, with people responsible for reviewing the work. Applicable development work includes 30 days of corrective maintenance after production launch.
Who owns the ad accounts, the data and the work?
Your materials, data and accounts remain yours, and we prefer to work in advertising and analytics accounts you own, with access delegated to our team. Agreed ownership rights in bespoke deliverables transfer under the engagement terms and applicable payment; third-party software and assets keep their licences. We do not withhold customer-owned data or accounts over a payment dispute.
What if we want to stop?
Cancellation, notice and any renewal terms are written into your proposal or statement of work before you accept it. If an engagement ends early, we hand over completed, paid-for work and list any unfinished work separately. For an eligible specialist trial, you can stop within the trial window and pay nothing for eligible trial hours.
How will we know what you are doing?
Before work starts we agree how often you get updates, what the reports cover and who sends them. You know who coordinates your engagement, who owns the work and how to escalate an issue. For hourly and retainer work, time is recorded in Workstatus, so you can see the time records behind your invoice.
A chatbot answers a question, grounded in your documentation, one turn at a time, and escalates to a human when it's uncertain. An agent is given a goal, not a question, and works toward it across multiple steps. At each step it decides what to look up, which tool to call, and what to do next based on the result. A chatbot's job ends at a good answer. An agent's job is to plan and execute a sequence of actions, which is why it needs tighter permission scoping and approval gates, not looser ones.
Workflow automation runs one path you've already mapped, reliably, at volume (intake, triage, data entry) with a human checkpoint wherever that fixed path hits a judgement step. An agent has no single fixed path: given a goal and a set of tools, it decides at each step what to do next. The sequence can genuinely vary run to run. That flexibility is the point, but it's also why the guardrails are designed differently. You can't checkpoint "the judgement step" when the steps aren't fixed in advance, so the checkpoint sits on the class of action instead: anything irreversible or above a threshold, wherever it falls in the run.
Any language model can make a wrong call. Anyone promising an agent that never will is selling something. What we control is what a wrong call can actually do. Each tool call carries only the access that step needs, never a blanket key to your systems. Anything irreversible or above a threshold you set waits for a human's approval before it executes; and before the agent is trusted unsupervised, it runs against an evaluation suite scored against your own baseline. Every step and its reasoning is logged, so a wrong call is visible and traceable, not silent and compounding.
Your existing tools: that's the brief, not a constraint we work around. The agent calls the CRM, ERP, helpdesk, internal APIs and spreadsheets you already run through defined tool integrations, rather than requiring a migration first. We're deliberately model-agnostic too: the model underneath is chosen in discovery on fit, cost and data residency. The integration layer is structured so it can be swapped without rebuilding the agent around it.
Supervised, against real scenarios drawn from the actual task: not a synthetic benchmark, and deliberately including cases where the obvious next step is the wrong one. We measure whether it calls the right tool, whether it recognises when it doesn't have enough information to proceed, and whether it holds for approval when it should. Scores are measured against your own baseline, you see them before sign-off, and the suite re-runs whenever the tools or the underlying data change.
It depends on how many tools it needs to call and how tightly the permissions and approval rules need to be scoped, which is why we don't quote from a rate card. Every engagement opens with a scoped pilot: one real task, a working agent, priced as a small, defined build. The proposal you receive itemises what ships: the tools wired, the guardrails and evaluation included, and what handover looks like. Extending an agent to further tasks or tools is priced only after the pilot has earned it against your own baseline.
Scope a pilot: one task, the tools it may call, a working agent with scoped permissions, a person's approval before anything irreversible, and every step logged.
