Capability Details

Agent

Business agents that can look things up, make judgements and give advice, connected to WeCom, PC and mobile.

01 / Technology decisions

Three trade-offs you cannot avoid

Each has its own cost; here is which side we chose and why.

How to wire in tools: let the model choose, or hard-code the flow

Common practiceGive the tool list to the model and let it decide which to call

AlternativeHard-code the business flow; the model only fills parameters

Our approachHard-code the process skeleton and let the model decide the branches

Letting the model call tools freely is impressive in a demo and uncontrollable in production — the same question may take three different tool chains, and failures cannot be reproduced. Hard-coding everything throws away the value of an agent. Our approach: the main flow is fixed (check the asset ledger, then the knowledge base, then advise), while the model decides whether to look something up and which category to look up. That keeps both control and flexibility.

What happens on failure: retry, degrade, or fail loudly

Common practiceRetry three times on failure

AlternativeFall back to the rules engine on failure

Our approachRoute by failure type: retry network errors, degrade on logic errors, return an error immediately on permission errors

Blind retries amplify the problem when the tool itself errors (duplicate ticket submission, for example). Our routing rule: retry on timeouts and rate limits; on 'not found', degrade to a rule-based fallback; return permission or parameter errors immediately without any retry.

How people and agents work together: fully automated or human in the loop

Common practiceFully automatic, no human in the loop

AlternativeA human confirms every step

Our approachRead operations fully automated, write operations require confirmation, high-risk operations reviewed by two people

Full automation is fine for reading data, but once it involves editing a ledger or submitting an approval, mistakes are expensive. So we grade operations by nature: read-only is open, writes require confirmation, and deletions or cross-system actions need two-person review.

02 / Option comparison

One problem, three approaches

There is no optimal solution, only solutions that fit the scenario.

Solution	Control	Coverage	Maintenance Cost	Who it suits
Prompt-only + single-turn tool calls	High	Narrow (single-step only)	Low	Q&A assistant, single-query scenarios
Fixed workflow plus a model filling the parameters	Very high	Medium (only where the process covers it)	Medium	Processes with stable flows, such as repair requests and approvals
Process skeleton + model decisions + tool orchestration	Medium-high	Wide	High (requires ongoing tuning)	Scenarios needing several systems to cooperate and judgement calls

Control and coverage are inherently in tension. Which to choose depends on the cost of error and the complexity of the scenario.

What we do

Equipment Steward · Exhibition Hall AI Operations Agent
402-fault knowledge base · 66-device register · 55 device types
WeCom / PC / mobile integration
Agent orchestration and tool calling

Discuss requirements

Delivery format

Deployment modelOn-Premise / Private Cloud / Intranet

Scope of deliverySystem + Documentation + Training

Maintenance supportRemote + on-site

Source Code DeliveryNegotiable

Related Cases

Proven systems

Client names are anonymized per confidentiality requirements.

In-House Product / Agent

Equipment Operations Agent (In-House)

Background: With so many equipment types, troubleshooting depends on the manufacturer and response is slow.
Solution: Fault diagnosis agent: knowledge-base driven, locates faults and recommends remediation, integrated with WeCom.
Technology: Fault knowledge base (402 entries) · Equipment register (66 units / 55 types) · WeCom / PC / mobile
Outcomes: Common faults can be diagnosed without assistance, reducing dependence on the vendor, with traceable remediation advice.

Port / Agent + Consortium Chain + App

Large Container Port · Smart Safety Training Centre

Background: A container port ranked among the top in China by annual throughput. Its existing training was mostly classroom lectures and could not cover hands-on practice for high-risk operations.
Solution: Comprehensive safety training centre + training and assessment platform + mobile learning. 7 assessment systems, 9 software modules, a 3-node consortium chain.
Technology: FISCO BCOS consortium chain (PBFT) · transcripts anchored on-chain via SHA-256 · node.js back end · Android client · 3D model interaction
Outcomes: Training records verifiable on chain and tamper-proof transcripts; covers 55 equipment categories and 66 equipment ledger entries.

View all case studies

03 / Implementation path

How many steps from zero to launch

The order cannot be reversed: starting with write operations or multi-step orchestration makes errors very hard to trace.

List available tools

Turn the existing system's interfaces into a tool list, each with explicit inputs, outputs and failure returns. Skip this and everything after is guesswork.

Draw the shortest closed loop

Pick the narrowest possible scenario (for example, 'when was this equipment last serviced?') and get ask → tool call → answer working end to end. Do not start with multi-step orchestration.

Add failure fallbacks

List every failure case and define a handling strategy (retry / degrade / raise an error). This step decides whether the agent can go to production.

Expand to multiple steps

Chain two adjacent tools together and add a decision branch. Every added step means re-running the regression cases.

Connect write operations + human in the loop

Connect operations that change data last, and always with a confirmation step. The order cannot be reversed — start with writes and errors become very hard to trace.

04 / Key metrics

Verifiable Numbers

No adjectives; write the specifications.

Steps per taskSteps 1–6　Beyond 6 steps, split into multiple agents

Tool-call success rate≥ 95%　Below this, fix the tooling first — do not tune the model

End-to-End Latency3–20 seconds　Depends on tool response times and step count

Manual intervention rateWrites confirmed 100% of the time　Read-only operations: 0%

05 / FAQ

What technical leads ask most often

These are questions we have actually been asked, answered without marketing spin.

Will the agent call tools at random?

No, as long as the tools themselves have permission boundaries. We do not give an agent more permission than the business needs — query tools get read-only access, and write tools must require confirmation. Enforcing permissions through prompts is unsafe; it must be done through system permissions.

What if several systems have inconsistent interfaces?

Write an adaptation layer. Normalise each system's interface into a single tool-description format (name, parameters, return structure) so the agent only sees the unified layer. That layer is a one-off cost and makes adding tools fast afterwards.

How do you know the agent is doing it right?

Build a regression test set. Every time you change a prompt or a tool, run the cases and check whether the pass rate dropped. An agent without a test set breaks with every change — and you never know it broke.

Can it integrate with WeCom / DingTalk?

Yes. We have integrated WeCom, PC and mobile with a single agent backend, with the front end adapting message formats per channel.

What compute does on-premise deployment need?

Running a 7B-class model plus a vector store on one machine: start at 24 GB of VRAM. For higher concurrency, use multiple GPUs or add inference services. The exact sizing depends on concurrency and latency requirements.