Confidential
AI Operations Agent for the
Pending Order Dashboard
Pilot proposal — natural-language operations over your existing SIMS backend
| Contents | What it covers |
|---|---|
| 1 · Executive summary | What we propose, and what the pilot proves |
| 2 · What we understood | Your systems, and the gap this fills |
| 3 · The proposed solution | How the agent works, and the rules it obeys |
| 4 · Pilot scope | Supported operations, deliverables and exclusions |
| 5 · Delivery plan | Four to six weeks, and when the clock starts |
| 6 · Control, security and data | What leaves your network, and what does not |
| 7 · Responsibility | Where the line sits, in writing |
| 8 · Commercials | Fixed price and payment milestones |
| 9 · Assumptions and prerequisites | What has to be in place for the pilot to start |
| 10 · About Aveosoft | Company, engineering practice and AI products |
Five operations on one dashboard, working end to end, before you commit to anything wider
The pilot covers one workflow: the Pending Order Dashboard. A user types something like commit 5,000 of item 62205 against order 0020-1002. The agent works out what that means, shows the resolved order, customer, item and quantity back on screen, and waits. The user confirms it. Only then is the write sent to your SIMS backend.
Three rules shape the design. The agent never writes to Sage 300 or to any of your databases itself. A confirmed commit or shipment reaches Sage the same way it does today, through your SIMS backend and its DLL connector, with the same numbering, tax and validation rules your backend applies. No business logic moves out of your systems: validation, authorisation and allocation stay inside the SIMS backend, which remains the single source of truth. And nothing is written until the user has confirmed it on screen.
The pilot is deliberately small. Five operations, one dashboard, no replacement backend. Nothing in your current process is modified. If the agent were switched off tomorrow, your team would carry on with the dashboard exactly as they do now.
What the pilot proves - On your own data and your own rules, an instruction in ordinary language can be turned into a correct, confirmed and recorded action inside your systems, and when the agent is uncertain or wrong, a person catches it before anything is written. That is the question worth answering before anything wider. If the pilot proves the pattern, the roll-out can be phased to cover the remaining operations and the issues set out in your brief, one stage at a time.
We estimate four to six weeks, measured from the day the knowledge transfer session is done and the endpoints and information in Section 9 are with us, not from the date of order. Section 8 sets out the fixed price and the payment milestones.
Your dashboards already work. What is missing is the layer above them.
- You run Sage 300 ERP alongside SIMS, your own system for production, stores and dispatch. Your connector posts transactions between the two. Accounting and purchase teams work directly in Sage at the same time, and nothing we build may interfere with that.
- The Pending Order Dashboard already does its job. It shows pending orders by location, the stock available against each line, and what is already committed. From there your team commits or releases stock and creates shipments, with your allocation rules and validations applied. The same screen also launches production planning for lines without stock, records advance payments, and feeds the shipments it creates to your dispatch flow. You do not want any of it rebuilt.
- You are rebuilding SIMS as a web application over APIs your own team has written, which use the Sage DLL underneath. The pending-order part of that rebuild is in test at the moment, and the endpoints this pilot needs may not all be exposed yet. Section 5 says what happens if one is missing, and Section 9 lists exactly what we need.
- What does not exist is the layer above it. A salesperson or planner still has to open the dashboard, filter, select the line, and click through each step. The pilot replaces that sequence with a typed instruction and a confirmation. In time the same actions can be driven by voice.
This proposal addresses that layer, and only that layer.
Your backend keeps the authority. The agent only ever proposes.
Your logic, not ours
Allocation, validation and authorisation run inside your SIMS backend. Tax, discount and stock come from your Sage masters and Sage recalculates on posting, exactly as today. We rebuild none of it.
Nothing we build holds a business rule
Our engineering layer is five fixed functions, each calling only the endpoints you designate for it. No replacement backend, and no rule of ours between you and Sage.
You confirm before anything is written
Every write action is shown back on screen and must be confirmed by the user before it is sent. The confirmation, and who gave it, is recorded. Read-only questions need no confirmation.
How an instruction is processed
This is where an AI layer usually goes wrong, so we set it out step by step.
- The model receives the typed instruction and a fixed description of the five operations. It returns a structured command (operation, order, item, quantity) and nothing else. It never returns free text that gets executed, and it never writes.
- Ordinary code takes that command and calls your read endpoints to resolve it: this order number, this customer, this item, this available quantity. Your data does the resolving, not the model's memory, so there is no question of it inventing an item that does not exist.
- The resolved record is shown on screen for the user to confirm.
- On confirmation, the write call you designated for that operation is made once, with the parameters shown. The response your API returns is recorded and displayed as-is.
The engineering layer
What we are proposing is not an AI model with access to your systems. It is our engineering layer, built for your five operations, with a model behind it. The model never sits on top of your database through any tool, harness or direct database access. It reaches your system only through your established APIs, and the engineering layer controls the model and the set of instructions it may act on. Neither OpenAI, Anthropic nor Google is given access to SIMS, Sage, your API or your databases. The model receives the typed instruction and returns a structured command, and that is the whole of its role. On our earlier calls we described this as the engineering vertical.
Every operation performed through the agent can therefore be traced and audited, and every one of them follows the rules, validations, permissions and business logic already implemented in your system. A layer that let the model read from and write to your database directly would be faster to build. It is not a viable option here. It would open the door to data loss or wrong entries caused by a hallucination or an unintended action, and it would give up the traceability and control your APIs already provide.
The same applies to a general-purpose agent given your API and told to work out what to do. It will be right most of the time and wrong occasionally, and nobody will know which until the stock is wrong. We do not build that way for operations that post to Sage. In this design the model cannot improvise: it has five things it can ask for, your data resolves them, and a person confirms before anything is written.
Why the confirmation step matters
You hold roughly 100,000 item codes, and your order numbers run in close sequence. The risk is not an obviously wrong instruction. It is a plausible one: 0020-1003 where 0020-1002 was meant. That would pass a quick glance. So before any write, the agent puts the resolved customer, order, item and quantity on screen, taken from live data, and waits for confirmation.
Five operations on one dashboard, and a plain list of what is excluded
Supported functionality
| Operation | What the agent does | Confirmation |
|---|---|---|
| List orders | Returns pending orders for a location, optionally narrowed by customer or item, by the parameters your list endpoint supports. | Not required |
| Filter orders | Refines a returned list by any field it contains, for example customer group, order number, item number or PO number. | Not required |
| Fetch order details | Returns the position your endpoint gives for a single order: quantities, committed stock, availability and status. | Not required |
| Commit and de-commit stock | Reserves or releases stock against one named order line, after the user who typed the instruction confirms the resolved record on screen. | Required before the write is sent |
| Create shipment | Creates a shipment for one named pending order, for a quantity up to the pending or committed quantity, from floor or rack stock as the instruction says (the agent asks if it does not say), using your existing allocation rules and validations, after the user confirms the resolved record on screen. The FIFO run that clubs several orders of a customer group into one shipment is not part of the pilot. | Required before the write is sent |
Deliverables
- The agent service deployed in an environment agreed with you
- A web portal through which instructions are issued and write actions confirmed. The pilot provides one login for one user, with no role-based access
- Integration with your SIMS backend APIs for the five operations listed above
- A record of actions taken through the agent: the instruction, the user who confirmed it, the result returned by your backend, and the timestamp. It is stored in a database inside your environment and can be exported to CSV
- Source code for everything we build, transferred to a repository belonging to APL on receipt of the final payment
- A working session with your team to hand over what we have built
The pilot user, and how the agent identifies itself
This matters because it affects what your systems record. The pilot provides one login to the portal, for one user. Every instruction and every confirmation is recorded against that login, with the time, in the action record.
The agent calls your SIMS backend with the single access token you issue. So inside SIMS and Sage, the transaction carries the agent's identity, in the same way any integration account would. Multiple users, each with their own identity reaching the backend, belong to a production rollout.
Not included in this pilot
Set out plainly, so expectations are clear before work starts:
- Role-based access control - The pilot provides one login for one user. Multiple users, separate roles for, say, salespeople and planners, or a separate approver role, belong to a production rollout
- Any operation outside the five listed above - On this same dashboard that means production planning and job-card creation, and advance-payment entry. It also means the FIFO allocation run that clubs several orders of a customer group into one shipment, which lives in your auto-invoice flow, and elsewhere invoicing, dispatch, scanning, labelling and price-list updates
- Changing the discount or tax on a shipment - The pilot creates shipments with the values your masters apply
- Per-action modes - In the pilot the modes are fixed: reads need no confirmation, writes always do. Per-action switching that you control yourselves is a production feature
- Voice input, and messaging channels such as WhatsApp or Telegram - These are later-phase options, not pilot deliverables. They would plug into the same engineering layer
- Any change to SIMS, to your connector, to Sage 300, or to the synchronisation between them
- Any middleware or replacement backend between your SIMS backend and Sage - The engineering layer in Section 3 sits above your API, not between your systems
- Formal user documentation and training programmes - A full written test plan covering failures, duplicates, interruptions and concurrent users is also outside the pilot; the one-page demonstration checklist per operation in Section 5 is what the pilot uses
- Formal security testing - The pilot runs only against your test environment; testing belongs to the production rollout
- Automated reconciliation reporting between SIMS and Sage
Four to six weeks, measured from the day knowledge transfer is done and the endpoints are in our hands
We estimate four to six weeks. The clock starts on the day the knowledge transfer session with your team has been held and we have working endpoint access to your test environment for the five operations, together with the documentation and information listed in Section 9. It does not start on the date of order. Without the knowledge transfer and endpoint access there is no work we can usefully begin.
| Stage | What happens |
|---|---|
| Week 1 | Detailed mapping, building on the knowledge transfer session. We map each of the five operations to your API endpoints, confirm the validations and authorisation gates behind them, and agree the exact request and response behaviour we will rely on. We also agree the demonstration checklist described below. |
| Weeks 2–3 | Read operations built and working against your test environment: list, filter and fetch order details. Your pilot user tries them and tells us where the language does not match how your team actually speaks. |
| Weeks 4–5 | Write operations built with the confirmation step: commit and de-commit stock, then shipment creation. Each is demonstrated on your test environment against the agreed checklist before it counts as done. The working demonstration of all five operations closes this stage. |
| Week 6 | Deployment in the environment you nominate, handover session, action record delivered, and a joint review of what the pilot showed, including where it fell short. |
What "done" means - In week 1 we agree a one-page demonstration checklist for each operation: a correct instruction, a wrong-but-plausible order number where the confirmation screen must show enough for the user to catch it, a quantity beyond what is available, an API error and, for commit, the matching de-commit, so both sides see the trail. An operation counts as done when it passes that checklist on your test environment in front of your point of contact. That is also what the payment milestones in Section 8 are measured against.
What would move this date - The main risk to the schedule is not development time. It is waiting on endpoint access, documentation, or an answer about how a particular rule works. The table shows the six-week case; four weeks is achievable when endpoints and test data are complete on day one and behave as documented. If an endpoint we need does not exist yet, that becomes a joint decision at the time: your team builds it, or we agree together how that operation is handled. We will tell you the day we find it, not at the end.
What leaves your network, and what never does
What is sent, and what is not
The model does one job: it turns the typed instruction into a structured command (the operation, the order number, the item and the quantity). Everything after that point is ordinary code calling your API. So what reaches the AI service is the instruction text, and nothing else. If an instruction could match more than one order or item, the agent asks the user to choose from what your data returned; the model is not consulted again. Your databases are never exposed to the model, no bulk export is sent, and no drawings, documents or attachments are sent. The confirmation screen, the action record and the calls to your backend involve the AI service not at all.
Customer names: yes. When a user names a customer in an instruction, that name goes to the AI service so the instruction can be interpreted. Prices, order values, stock on hand and drawings: never, because the agent does not pass your API responses to the model. Masking customer names before the text is sent is available as an option; because it needs a lookup against your customer master, we would confirm it in week 1 and only commit to it if that lookup is available.
The AI service, and how it is chosen
The agent runs on a commercial AI service, on business API terms rather than the consumer products. We work with OpenAI, Anthropic (Claude) and Google (Gemini). We test candidates on sample instructions before kick-off, recommend one in week 1 together with a usage-cost range, and you approve it in writing before any of your data is sent.
The code is written against a single adapter, so changing service later is a configuration change plus a re-run of our instruction tests, not a rebuild.
| Point | Position |
|---|---|
| Who chooses | You do. We recommend, you decide, and we use no other service without your written approval. |
| Monthly usage cost | Only the interpretation of a typed instruction uses the AI service; listing, fetching, committing and creating shipments are ordinary calls to your backend with no per-use AI cost. We give you a monthly range before implementation. You set a monthly budget and alerts on the account, and the agent itself stops accepting instructions at a monthly limit you choose. Billed at cost to your own account, never resold or marked up by us. |
| Account and keys | Opened in APL's name, so you see the usage and the billing directly and can revoke access at any time. |
| Retention and training | On the business API terms of all three, the provider does not train its models on your data. Prompts may be held for a short abuse-monitoring period and then deleted. We will give you the provider's written terms for whichever you approve, before anything is connected. |
| Excluded | Lower-cost services hosted in China. Using them would place your customer names and order values in a jurisdiction where no agreement we sign for you could be enforced. |
Credentials
We authenticate to your APIs using an access token that you issue and can revoke at any time. Your Sage credentials and server credentials stay where they are today. They are never shared with us. The access token is held in the agent's configuration on your server, never in source code or in a repository.
Revoking that token is your emergency stop - Every agent call, read or write, stops at once. Your dashboard is unaffected, and the agent holds no queue, so nothing is sent later.
If the AI service is unavailable, the agent stops accepting instructions. Your dashboard and everything behind it carry on.
Who carries responsibility when something goes wrong
Responsibility for an automated action needs to be clear before work starts, not after something has gone wrong. Here is where the line sits.
- Ours - Defects in what we build: how an instruction is interpreted, what the user is shown on the confirmation screen, and the call made to your API. If, during the pilot, a fault on our side sends a wrong or duplicate call after a correct confirmation, we fix the defect at no cost and identify every affected transaction from the action record within one working day. Reversing a posted transaction is done in your systems by your team, because only your systems can do it, and we will support that at no charge.
- Yours - What your backend does with a correct, confirmed request is governed by your own business logic. The agent does not change or override it.
- Duplicate safety - The agent never retries a write on its own. If your API returns an error, the user sees your message and nothing further happens. If a write times out, the agent stops and tells the user to check the record before trying again, rather than guessing. Each write also carries a unique reference so that a repeat can be recognised. If your API can use that reference to reject a duplicate, the protection is end to end; if not, the stop-and-check behaviour is what prevents it. We will confirm which applies in week 1.
- Proof before acceptance - Every write operation is demonstrated on your test environment, using representative data, before it counts as done. Nothing in this pilot is tried for the first time against live operations.
- A comparable implementation - You asked in your brief to see one. We have not previously connected an AI agent to Sage 300 or to a system like SIMS, and we would rather say so than stretch an example to fit. We have connected agents to other business systems: a courier client's booking system, for example, where the agent schedules, reschedules and cancels pickups through the client's own API with a fixed list of permitted actions. That is the pattern here: a bounded set of actions, business logic kept outside the model, and a person in front of anything that writes. It is also why the pilot is small, why every write is demonstrated on your test environment before it counts as done, and why the source code is handed to you at the end.
A fixed price for the pilot, paid in three milestones
The pilot is offered as a single fixed price for the five operations in Section 4. The price does not change if the work takes longer than we estimated, provided the prerequisites in Section 9 are met. Delays in access or answers on your side move the dates, not the price. Any change of scope is quoted separately, and only with your written approval.
| Item | Amount |
|---|---|
| Pilot implementation: the five operations, the web portal, integration with your SIMS backend APIs, and handover | ₹1,80,000/- · GST extra as applicable |
| AI service usage | At cost, billed directly to your own account (Section 6) |
Payment milestones
| Share | When | What has happened by then |
|---|---|---|
| 40% | On order confirmation | Advance, before work starts. |
| 50% | On the working demonstration of all five operations | The agent, running from our environment, performs all five operations against your test environment in front of your team, against the agreed checklist. This is the end of the week 4–5 stage in Section 5. |
| 10% | On go-live | The agent is deployed in the environment you nominate and the handover session is done. This is the week 6 milestone in Section 5. The source code is transferred to your repository on receipt of this payment. |
Payment is due within 2 to 3 days of each milestone being completed. GST is extra as applicable.
Not included in the fee
- AI provider usage, which is billed to your own account and visible to you directly
- Server capacity for hosting the agent and the portal
- Any third-party licences, none of which are anticipated for this pilot
- Work outside the scope in Section 4, which would be quoted separately and only with your prior written approval
What the pilot assumes, and what has to be in place for it to start
The estimate and the timeline rest on the assumptions below. If any one of them does not hold, the scope or the schedule will change. We would rather set them out now than find the gap midway through the build.
Assumptions about your systems
- Business logic sits in the backend, not the frontend - We assume all business logic, decision-making, validations and authorisation gates are implemented in the SIMS backend rather than in the screens. The agent takes the place of the frontend and talks to the backend directly. Any rule enforced only in the interface would therefore not apply to the agent. This is the assumption most worth checking in the first week: if a rule turns out to live in the screens, we will tell you, and either your team moves it into the API or we agree together how that operation is handled.
- The backend returns meaningful responses - We assume each operation returns a clear response, including when it fails, so the agent can tell the user what happened rather than guess.
- The backend is the single source of truth - All reading and writing during the pilot is performed through the existing SIMS backend APIs. We will not introduce middleware or a replacement backend between SIMS and Sage.
What we need from your team
| Item | What it needs to contain |
|---|---|
| API access and documentation | All endpoints relevant to the five operations, with request and response structures, validation rules, authentication requirements, the business rules applied, and the possible error responses. Anything else needed to integrate the API correctly. |
| Access token | An access token, issued by you, that lets the agent call the SIMS backend APIs for the five operations. You control its scope and can revoke it at any time. We do not need, and will not hold, your Sage or server credentials. |
| The calls behind the five operations | For each of the five operations in Section 4, the exact endpoint or endpoints it maps to, with parameters and responses: for example, whether commit and de-commit are one endpoint or two, and what shipment creation expects. This fixes what the agent can be instructed to do. |
| Knowledge transfer | Working sessions covering the business logic, validations, decision points and authorisation gates behind each action in the Pending Order Dashboard. The first session is what starts the clock in Section 5. |
| Existing documentation | Wherever they exist: flowcharts, architecture diagrams, sequence diagrams and process documents showing how data moves through the current system. We do not expect these to be written for us; we ask for what is already there. |
| Test environment | Access to a non-production environment with representative data, so that nothing during the pilot touches live operations. |
| A point of contact | One person on your side we can go to with questions about the business logic or the API, and who can unblock access when needed. |
| Hosting | Somewhere to run the agent and the portal: one virtual machine inside your network, or a cloud account in your name. We will confirm the sizing in week 1. Hosting cost sits with you and is not in our fee. |
Why we are asking for this much - We need to understand how the system behaves today, so the agent works with your backend in the same way your own application does. Where a rule is unclear to us, the agent will get it wrong in a way that is hard to spot later.
An AI-first engineering company, with AI products of our own in production
Aveosoft Pvt. Ltd. is an AI-first software engineering company headquartered in Ahmedabad, Gujarat. Since 2016 we have built digital infrastructure for government departments and enterprises across India and beyond, in environments where complexity is high and the software has to work every day.
Our own AI products, running in production
We are not only a services company. We build and run our own AI products, and the engineering practice behind this proposal comes from that work.
Cloneify AI
LLM-powered workflow automation for business operations
A platform that lets businesses build AI agents to handle parts of their operations without writing code: triaging email, summarising calls, qualifying leads, generating content, and connecting to internal systems. Cloneify is built on the same discipline this pilot needs. Give the agent a bounded set of actions. Keep the business logic outside the model.
RingFront AI
A 24/7 AI voice receptionist. It answers every call in a natural voice, books appointments straight into the calendar, and transcribes the conversation for follow-up. Voice is the later-phase channel for this system, and it is something we already run rather than something we would learn on your project.
Engagement entity - Aveosoft Pvt. Ltd., Ahmedabad, Gujarat, India · aveosoft.com
Contact - Keval Gajjar · kg@aveosoft.com · +91 88660 09589. Client references are available on request.