Start with one useful workflow
Consider a sales coordinator who asks for a customer's current follow-up rule and wants to draft a CRM task. The answer needs both an approved operating policy and the customer record the coordinator is allowed to access. The assistant should cite the policy revision, identify missing evidence and show the proposed task before any record changes.
An Arabic question and its English equivalent should use the same access rules and business identifiers. For example: “What is the follow-up policy for this customer?” and “ما سياسة المتابعة لهذا العميل؟”. Translating the question must not change who can read the record or approve an action.
The proposed architecture
Keep the model, knowledge sources and tools behind explicit application boundaries. The model can propose an operation; the application decides whether it is allowed.
- 1. Identity and access
- A trusted login service establishes the user, organization and permissions. Derive these from the authenticated session, never from a prompt or a model-supplied tenant ID.
- 2. Authorized retrieval
- Filter documents and business records by the user's permissions before returning evidence. Preserve source IDs, revisions and freshness information. If essential evidence is unavailable, stop or ask for clarification.
- 3. Bilingual response
- Send only permitted evidence to the selected model. Require citations and an explicit response when evidence is missing. Treat retrieved instructions as document content, not permission to call tools.
- 4. Tool adapter
- Expose narrowly defined CRM/ERP actions through a reviewed API adapter or MCP server. Validate the operation and its arguments, and recheck access on the server at execution time.
- 5. Approval and execution
- Show the exact proposed change to an authorized person. Bind approval to the actor, organization, action and payload; give it an expiry and prevent reuse. Revalidate changed records before committing the action.
- 6. Audit and operations
- Record the decision, source references, approved operation and outcome. Keep credentials and unnecessary source text out of logs. Set retention, access, monitoring and recovery responsibilities for the actual environment.
How to evaluate Arabic and English retrieval
RAG combines retrieved evidence with model-generated answers. A bilingual interface alone does not establish retrieval or answer quality. Select the retrieval method and model against representative company material, then evaluate each language separately.
Build a review set with Arabic questions, English equivalents, mixed-language names, product identifiers, dates and questions that the sources cannot answer. Include stale policies, unauthorized records and document text that tries to redirect the assistant.
- Evidence quality
- Check whether the required permitted passage was retrieved and whether each factual answer is supported by its cited revision. Record missing evidence and unsupported statements.
- Language quality
- Review Arabic terminology, English terminology and equivalent business meaning with the intended users. Include dialects only where the project requires them.
- Access and action quality
- Check denied reads, attempted cross-organization access, approval bypass and repeat execution. Run the same cases in both languages.
- Operational fit
- Measure end-to-end latency and cost on the chosen deployment. Agree acceptance thresholds before the pilot; this guide reports no production accuracy or latency benchmark.
Decide where the system runs
For a customer-controlled environment, agree the hosting location of the application, model, retrieval store, connectors and audit records separately. A local application can still send evidence to an external model; an MCP connection can still execute a worker on a hosted endpoint.
Begin with a sandbox connector and a read-only account. Agree the record-level access policy, approved write operations, identity integration, secret storage, egress restrictions, log retention, rollback and handover. Validate these in the intended environment before enabling production writes.
The AgentMug MCP bridge calls its configured endpoint; it does not by itself provide an on-premises deployment. Our open components and product documentation are engineering evidence. Hosting terms, licenses and customer-specific controls need their own assessment.
What a first pilot should deliver
Scope one workflow, one knowledge source and one connected system. Review the result together before extending its permissions or coverage.
- A reviewed design
- A data-flow diagram, an inventory of sources and tools, the identity boundary and the proposed hosting arrangement.
- A tested connector
- A sandbox read path and, if required, one approved write operation with error handling, record-version checks and retry behavior.
- A bilingual evaluation
- An agreed set of representative questions and forbidden actions, with observed results, source references and remaining failures.
- An operating handover
- Run instructions, configuration ownership, incident and rollback procedures, and a decision on whether the evidence supports production use.
Plan a pilot you can evaluate
Use these free, editable resources to scope one workflow and agree what success means before development. The brief works for an internal-document assistant or a proposed CRM/ERP integration, with Arabic and English evaluated separately.
Download the AI pilot brief — English text
Download the bilingual evaluation worksheet — JSON
The worksheet contains eight scenario pairs: supported answers, missing evidence, stale evidence, conflicting sources, denied access, unapproved actions, document instructions and duplicate execution. Replace the placeholders with approved test data; record actual results after running your system.
- Establish the baseline
- Record the current manual process, sample size, completion time and error definition. Compare the pilot on equivalent tasks, including human review and correction time.
- Agree the decision rules
- Set language-specific quality targets, permitted actions, critical failure rules and cost/latency limits before testing. Keep a holdout set that is not used for tuning.
- Keep an inspectable record
- For each run, retain the source revision, permissions, model/configuration version, answer, proposed action and reviewer decision. Report failures and the denominator alongside every percentage.
- Decide what happens next
- Choose proceed, revise or stop from the observed evidence. Agree an owner, monitoring and rollback before enabling production access. Publish customer outcomes only with permission.
These are planning templates, not completed evaluations or customer results. The example scenarios have no populated measurements and do not establish a certification or production-readiness standard. Do not put credentials or unredacted customer data in a public copy or the contact form.
Run the access and approval example
Download the dependency-free JavaScript file and run it locally with Node.js 22 or newer. It uses fictional users, documents and CRM records. It demonstrates an allowed evidence read, denied access, missing-evidence abstention and an approved task, then prints structured audit receipts.
Download the verification tests
Save the example and tests in the same folder. Run with Node.js 22 or newer:
node business-assistant-reference.mjs --lang en
node --test business-assistant-reference.test.mjs
This is a deterministic, in-memory control-flow example. Login is simulated and approval is scripted, with no interactive human-review interface. There is no network, model inference, semantic search, durable audit store or real connector. Passing its tests demonstrates only the illustrated checks. It is not a production security library, an Arabic RAG benchmark or an AgentMug integration.
What our existing products demonstrate
These public sources document individual components. They do not establish a completed customer deployment of the combined architecture above.
- AgentMug source contracts and runtime
- Documents private source bindings, readiness checks, evidence references and run receipts. Source adapters are read-only; retrieval and tool executors depend on the host.
- AgentMug MCP bridge
- Documents hosted worker invocation and inspectable source-readiness and receipt resources.
- AgentMug n8n example
- Provides an importable trigger-to-worker workflow. Connecting a particular ERP or CRM still needs a system-specific adapter and tests.
- AgentMug tracing adapter
- Documents model and transcription spans. The operator configures collection and retention; tracing is not a complete business audit system.
- KLYPIX retrieval and evidence
- Documents lexical retrieval and optional local semantic retrieval for project knowledge. It supplies no verified Arabic business-retrieval benchmark.
How we build portable AI workers with AgentMug