AI agents that do bounded, useful work inside your business systems.
Thalenor builds custom AI agents for businesses in India and internationally: agents that retrieve context, use approved tools, take constrained actions, pause for approval and log everything they do.
What is an AI agent, as opposed to a chatbot?
A chatbot answers questions. An AI agent completes a task. A real agent can retrieve context from your knowledge base and CRM, decide on a next step, use tools it has been given permission to use, pause when a human should approve, execute, and record what happened. Autonomy is scoped deliberately; the agent should never be able to do more than its permissions allow.
Read widely. Propose freely. Execute narrowly.
Every agent we build is described in these four verbs before any code is written.
Read
- Knowledge base
- CRM records
- Calendar
- Previous communication
Propose
- Draft a reply
- Suggest next action
- Prepare a summary
- Recommend a route
Requires approval
- Sending to a customer
- Changing prices or dates
- Anything irreversible
- Low-confidence decisions
Execute
- Log the activity
- Update a record it owns
- Schedule a follow-up
- Call an approved tool
One agent run, timestamped.
The task: prepare a follow-up for a qualified prospect. Reads are broad, the proposal is drafted, the send waits for a person, and everything is logged.
- 09:42:01Task created by the CRM stage change to 'Qualified'.
- 09:42:02Customer record and last three notes retrieved.
- 09:42:03Previous correspondence loaded; account status checked: active, no open tickets.
- 09:42:06Recommended response drafted, referencing the pricing question from the last call.
- 09:42:08Approval requested: external communication requires a person.
- 09:43:17Approved by Priya S. Email sent, CRM activity logged, task closed.
The agent cannot find a CRM record for the prospect.
Missing context is an explicit state. The agent never invents a customer.
A person is notified with what was searched and what was found.
Once the record exists, the run continues from where it paused.
Agents that fit a job, not a demo.
Support and service agents
Answer from your knowledge, look up orders, create tickets, escalate with context.
Lead qualification agents
Read enquiries, ask clarifying questions, score against your criteria, update the CRM.
Internal assistants
Answer staff questions from policies, documents and systems with citations.
Research and knowledge agents
Gather, compare and summarise information from approved sources (RAG).
Operations agents
Multi-step work across tools: prepare, propose, wait for approval, execute, log.
Autonomy without recklessness.
Every capability an agent has is a permission someone granted. We design agents so that reading is broad, proposing is encouraged, executing is narrow and anything irreversible waits for a person.
Task received to result logged.
Receive
A task arrives from a person, a schedule or another system.
Retrieve
Relevant context is pulled from knowledge, CRM and records.
Reason
The agent determines the next action within its scope.
Act
Approved tools are called; risky steps wait for approval.
Log
Inputs, decisions and outputs are recorded for review.
Anatomy of an agent that can be trusted with work.
The model is in the middle. Around it sit the pieces that make the agent bounded, observable and correctable.
Restricted tools, validated outputs, scoped actions, approval for anything irreversible.
Prompts and models are fallible. Deterministic checks surround every model output.
Model, retrieval and tools are separate components. Any can be replaced without a rebuild.
Straight answers to the questions that decide a project.
- Give an agent write access to systems before its read-only behaviour has been observed in production.
- Let an agent send external communication without a human approval step at launch.
- Describe a simple retrieval chatbot as an autonomous agent.
What if the agent does something it should not?
It cannot call a tool it has not been granted, and irreversible actions wait for approval. If a permitted action is wrong, the log shows exactly what happened so the scope can be tightened.
Will it hallucinate?
Models can. That is why retrieval is grounded in your documents with citations, outputs are validated against schemas and low-confidence cases go to a person.
Do we need a chatbot or an agent?
If people mostly need answers, build a grounded assistant. If a multi-step task has to be completed across systems, build an agent with permissions.
Can we see what it did?
Yes. Every run has a readable trace: what it read, what it proposed, who approved, what it executed.
Will we be locked into a model provider?
No. The architecture is model-agnostic and the tools are yours.
Questions worth asking first.
If the steps are always the same, a workflow is simpler and more reliable. Agents earn their place when the path varies, information has to be gathered from several places, or judgement about the next step is needed.
Describe the task you want handled.
Tell us what a good employee would do with it, step by step. That is the specification an agent needs.