Every session starts stateless; the MCP server provides excellent tools, but the real domain expert agent needs to know how to use these tools proficiently and intelligently. Additionally, they must be conscious of token consumption, as it is not abundant and time is critical. I don’t want to waste a lot of time and money on simple tasks. What is the right approach to building such a skilled expert agent?
It’s through a layered structure!
Knowledge reaches the agent through four channels, each with a different failure mode. Project memory requires the agent to know to check a specific path. Knowledge base (KB) files require the agent to search for them, meaning they must know what to look for. AGENTS.md auto-loads for one project but does not transfer between projects. Tool docstrings load with the tool list but only guide tool selection, not workflow. The skill file is different: it auto-loads when the task matches, providing the workflow framework, pitfalls catalog, and validation checklist directly into the agent’s working context before they write any code. This is why the skill file is the keystone. Without it, knowledge is scattered, and the agent either rediscovers or misses critical nuances every session. With it, the framework activates automatically, and the agent only needs to search the KB for specific data details, rather than for the workflow itself.
Adversarial edge-case testing is essential for AI, which I was previously unaware of. What this entails is conducting a focused session to test the existing adapter against known edge cases, delisted entities, suspended stocks, cross-listed entities, and China connect SDEOL swaps before the full project implementation. The results are documented in the edge-case behavior table, helping to uncover silent bugs, as anticipating these issues is part of this agent’s capabilities.
Moving forward, the agent should continue to accumulate knowledge and skills throughout the projects. Next, I will develop approximately five sufficient cases to establish this capability at a solid level.
Additionally, it must know how to validate its results effectively. Each phase includes validation checkpoints: after universe construction, verifying expected countries and exchanges, ensuring there are no missing identifiers; following eligibility, confirming that every threshold is met and all exclusions are documented; during classification, asserting every category is represented and each membership is traceable to a specific RBICS code or supply chain relationship; after selection, ensuring 51 to 60 names are covered, with all categories addressed and protected names retained; during weighting, verifying that the sum of upload weights equals exactly 100.000000 percent, with no caps violated and top-10 under 40 percent; after workbook generation, ensuring all tabs are populated and that Added and Removed items are consistent with previous and final results. These validations are not merely tests; they provide evidence that the result is trustworthy. When a human reviews the output, the validation evidence should preemptively address their questions. This is what 90 percent autonomy looks like: output accompanied by built-in evidence of correctness.
Lastly, we acknowledge that about 10% of cases will require human judgment, as documents could relate to headquarters or incorporation; human wording is inherently ambiguous, making it crucial for the agent to recognize uncharted territory and pass responsibility to humans for guidance.