Straight answers, before you talk to anyone.

A chatbot answers. An agent acts: it plans a sequence of steps, calls tools and APIs to change state in your systems, checks the result and either finishes or escalates. Chatbots need good retrieval; agents additionally need permissions, idempotency, budgets and traces.

Three layers: tools are permissioned and typed so an agent can only do what it was granted; irreversible actions pass through a human approval gate; and every run carries hard budget, step and time limits that terminate it. All of it is logged.

A scoped production agent covering one workflow typically takes six to ten weeks including evals and observability. A proof of concept against real data takes two to three weeks.

When the task has genuinely different modes of work — planning, retrieval, generation, verification, side effects — or when you need to evaluate and improve parts independently. If a single well-prompted call with two tools does the job reliably, keep it.

Usually LangGraph for the agent graph and Temporal where runs are long-lived or must survive infrastructure failure. We keep the orchestration layer thin enough to swap, because this tooling moves quickly.

Classic RPA follows fixed scripts against fixed screens and breaks when either changes. We automate against APIs where they exist, and use models for the judgement steps — reading a document, classifying an intent, drafting a reply — with rules and verification around them.

Yes. Where a client is standardised on Microsoft we build with Power Platform, Azure OpenAI and Copilot extensibility; elsewhere we use Temporal or n8n with our own services. The judgement layer is portable either way.

Constrain what the model can say: require retrieval with citations, verify claims against the retrieved span, and refuse when support is missing. Then measure it — an ungrounded-answer rate you track per release is what actually keeps it low.

Yes, and it is one of the most common ways we start. We instrument the existing system, build the dataset from its real traffic, and hand back a suite your team runs in CI.

Yes. We deploy inside your cloud account or VPC, use models with no-training data agreements or self-hosted open weights, and keep retrieval permission-aware so answers never cross a tenant or role boundary.

We have built retrieval over hundreds of thousands of pages. Scale is mostly an ingestion and indexing engineering problem; answer quality depends far more on chunking, metadata and reranking than on raw size.

Web, mobile app, WhatsApp Business, email and in-product surfaces, from one assistant definition so behaviour stays consistent across channels.

It says so and escalates. A confident wrong answer costs far more than a handover, so refusal behaviour is defined explicitly and tested in the eval suite.

Yes — we disclose it at the start of the call. Beyond being required in many jurisdictions, undisclosed AI callers damage trust the moment someone works it out.

Yes, with a warm transfer that passes the transcript and collected data to the agent who picks up, so the caller does not repeat themselves.

Model Context Protocol is an open standard for exposing tools and data to AI assistants over a consistent interface. Build the server once and any MCP-capable client can use it, instead of writing a bespoke integration per assistant.

Row-level with enforced policies covers most B2B SaaS and keeps operations simple. We move to schema or database per tenant when contracts demand physical separation, data residency differs per customer, or tenants are few and very large.

Yes. It is a migration project: introduce the tenancy boundary, backfill and verify, then cut over tenant by tenant with a rollback path at each step.

React Native for most products: one codebase, near-native feel, far cheaper to evolve. We go native when the app depends on heavy device capability — sustained camera processing, complex background work, deep platform integrations.

Yes. We start with an audit — architecture, test coverage, dependency and security risk — and give you a written assessment with options before we touch anything.

Yes — a till that stops when the internet does is not a till. We build local-first with a sync queue, conflict resolution and end-of-shift reconciliation.

Yes, and it usually works best that way — your admin holds the business context, we bring engineering capacity for the custom development and integrations.

Rates depend on seniority and skill, and we quote monthly per engineer with no placement fee. Tell us the role and the duration and you will get a number the same week.

Yes, and it often runs the other way too — teams start with a pod, then move a defined piece of work to a fixed-scope project once the requirements settle.