The short answer: the workflow determines the effort.
There is no single project price for an AI agent. Cost depends on its task, the systems it accesses and how its output is checked. Preparing a draft from approved documents differs from making changes across several systems. A price without a defined scope is difficult to compare.
An initial estimate needs a bounded workflow, its frequency, the systems involved and required approvals. These details do not replace a proposal. They reveal the assumptions that need resolving before investment.
Separate four cost categories.
Planning: capture the task and current effort, check data access, define boundaries and select test cases. Internal subject-matter teams also need time for this. Make this preparation explicit when comparing proposals.
Implementation: integrations, data preparation, agent logic, approvals, testing and rollout. Beyond the number of systems, suitable interfaces and a usable test environment matter. Missing access or inconsistent documents can create extra work.
Ongoing operations: model usage, hosting and other services, plus monitoring, troubleshooting and quality review. Separate usage-based costs from agreed support services. Ask what is included and what changes at higher volumes.
Development and internal effort: new tasks, changed sources or systems, knowledge maintenance, training and approvals. A working pilot does not remove this work. Record who owns it and how it is budgeted.
Use a transparent comparison.
Cost over your chosen period = one-off planning and implementation + ongoing usage and support + internal work + planned changes. Use the same period and case volume for each option. Compare assumptions as well as totals.
Estimated monthly time released = case volume × handling time actually avoided per case − additional review and rework time. Use consistent time units. A monetary value requires your own confirmed internal hourly rate. Available capacity is not automatically a cash saving.
Record the current workflow and compare similar cases during the pilot. Assess misclassifications, follow-up questions and quality alongside time. Increased rework or missing baseline data means a positive benefit is not yet established.
What to clarify before a proposal.
Describe one case from input to outcome: where is the information? May the agent only read and prepare, or also write? Who approves changes? How are unclear cases handled? Which failures must the workflow tolerate?
Request separate figures for one-off costs, ongoing costs, external services, internal participation and extensions. Ask for a limited pilot scope, acceptance criteria and a plan if testing does not justify proceeding. This makes a proposal an assessable decision.
How DTG assesses scope.
The collaboration described on this website comprises one-off implementation and monthly support with an agreed scope. Model usage and other third-party costs are considered separately. We do not quote a project price here because the task, integrations and support needs must first be defined.