Software, AI & Automation

AI assistants and agents with defined permissions

Home / Software, AI & Automation / AI Agent Development

Discuss an AI-assisted workflow with DeshTech by describing the task, information sources and actions involved. An agent needs defined permissions and evaluation; a conversational interface alone does not establish a reliable business workflow.

Discuss Your Project

01 / Service fit

Where this service fits

A searchable knowledge assistant, a structured automation and an action-taking agent are different choices. Use deterministic rules when they solve the problem more clearly. Start with a controlled demonstration or pilot and describe its limitations before treating it as a production service.

02 / Scope

What to plan in the scope

Knowledge and grounding

Identify approved documents and data, who maintains them and which users may access them. Distinguish an answer supported by a source from a generated suggestion.

Tools and approval

Limit the systems an assistant can read or change. For consequential actions, define human review, confirmation and an escalation route instead of giving broad unattended access.

Evaluation and operation

Agree representative tasks, expected answers and unacceptable behaviors. Plan logging, failure handling, model/provider changes and recurring usage costs before expanding access.

03 / Decisions

Choose the approach before the tools

Before giving an assistant a tool, decide whether it needs read-only access or permission to change records. Use the narrowest practical permissions and make consequential actions reviewable. Separate a demonstration with sample information from a deployed system with live customer data.

04 / Delivery

Design the pilot around evidence and permissions

Choose a narrow task and approved source set. Record the source owner, review date and access rules; prepare questions with expected evidence before selecting a model. Test supported, missing, contradictory and restricted information. Agree the pilot decision and operator handoff before enabling actions.

Illustrative assistant: answer or escalate

Sample interaction, not a live demo or client result.
Approved sample source: “Support requests go to the service desk; response times depend on the agreement.”
Question: “Where do I request support?”
Expected answer: “Contact the service desk”, citing that source.
Question: “What is my guaranteed response time?”
Expected behaviour: state that the source does not establish it and refer to the agreement.

Evaluate uncertainty and action requests

For “change this customer’s address”, a read-only assistant should explain its limit and route the request to an authorised person. A scoped action agent needs identity, permission and confirmation checks. The evaluation log should record question, source, expected behaviour, observed answer, citation, permission result and reviewer decision. Test unavailable sources, conflicting instructions and provider failure; do not fabricate an answer when retrieval fails.

05 / Budget and responsibilities

What affects the project estimate

Cost depends on data preparation, tool integrations, access rules, evaluation effort and ongoing model usage. Model output can be wrong even with grounding. Define the tasks that require human judgment and avoid promising unsupervised accuracy or savings.

A pilot proposal should separate source preparation, retrieval, model usage, tool access, evaluation and ongoing operation. Agree the provider and data handling before uploading business information. The sample above describes intended checks; it does not establish measured accuracy or a completed production deployment.

06 / Get ready

What to bring to the first discussion

Describe the task, intended users, source documents, access restrictions, languages and actions requested. Identify a person who can approve the source set and judge test answers. Use anonymised samples first; agree retention, provider processing, cost limits and human escalation privately.

Questions / Answers