This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content
Introduction
All hands on deck! Welcome to the NeoNomad!
This is my second time participating in a hackathon (and also my second post :D), and I am still shocked that I made it in my first try. After winning the prize, the one thing that hit me was getting the prize amount in my resident country. I had to fill out a W-8BEN to avoid double taxation, read the laws in my host country, and had to handle filing for the tax on the "income" generated. So, overall, a big headache. Which leads me to this: NeoNomad (Neo referring to Captain Nemo and Nomad meaning travelling from place to place), Cross-Border Tax Residency & PE Risk Arbiter.
Now, those are some heavy words; let us understand them in simpler terms:
The Persona: Meet Rohan
Imagine a software engineer named Rohan:
- Home Base: Rohan is an Indian citizen and tax resident living in India.
- The Employer: He works remotely as a Principal Solutions Architect for a high-growth tech company based in Germany.
- The Plan: He decides to do a winter detox and work remotely from a beach apartment in Valencia, Spain, for 128 days (straddling October through February).
To Rohan, the setup seems straightforward:
"I'm only staying four months, well below the famous 183-day limit. I'm paying my regular taxes in India, and my employer is a German company with no presence in Spain. Why would this cause any tax issues?"
However, behind that simple intuition lies a hidden cross-border trap where three jurisdictions and their tax laws collide simultaneously.
In reality, three distinct legal frameworks collide simultaneously:
-
Spain's Unilateral Domestic Tax Law (LIRPF & IRNR):
- Under domestic Spanish personal income tax (Ley 35/2006 LIRPF Art. 9.1(a)), tax residency requires strictly more than 183 days within a single calendar year. Because Rohan's 128-day stay straddles two tax years (78 days in 2026, 50 days in 2027), he does not trigger statutory domestic tax residency.
- However, under Spain's Non-Resident Income Tax Act (IRNR Art. 13.1(c)), Spain asserts strict territoriality: any labor physically conducted on Spanish soil is deemed Spanish-source income, taxable immediately from Day 1 at a 24% non-resident rate, regardless of where the employer is incorporated.
-
International Treaty Supremacy (India–Spain DTAA Article 15):
- Rohan is an Indian tax resident, so his personal income tax relief is governed by the India–Spain Double Taxation Avoidance Agreement.
- Under Article 15(2), host-country taxation is displaced if:
- The individual is present for <= 183 days in a rolling 12-month period,
- The employer is not resident in Spain (the German company satisfies this), and
- The remuneration is not borne by a Spanish permanent establishment.
- Under Article 96 of the Spanish Constitution, ratified international treaties supersede domestic legislation, legally nullifying Spain's domestic Day-1 IRNR claim.
-
Corporate Permanent Establishment Exposure (Germany–Spain DTAA Article 5):
- Even though Rohan's personal income is shielded by the India–Spain treaty, his employer's corporate exposure is governed by an entirely different instrument: the Germany–Spain DTAA.
- Because Rohan scopes custom architectures and negotiates commercial Statement of Work (SOW) terms on the ground with European automotive accounts, the German company faces a high risk of triggering a Dependent Agent Permanent Establishment (DAPE) under Article 5(5). Digital DocuSign execution back in Germany does not eliminate this liability under modern OECD rules.
This brings us to the Sanity MCP context and Knowledge bases:
What I built:
Sanity is basically a smart data store, I would say, with relationships clearly defined between entities without any conflicts or duplication.
An agent is only as good as the knowledge it can find
So, what I built was the initial schema containing the jurisdication: containing information about the independent country and the bilateral treaties between these independent countries.
Providing the schema outline here:
Example 1: India–Spain DTAA (treaty-in-es)
JSON
{
"_id": "treaty-in-es",
"_type": "bilateralTreaty",
"title": "Convention Between the Republic of India and the Kingdom of Spain for the Avoidance of Double Taxation",
"signatoryA": {
"_type": "reference",
"_ref": "jurisdiction-in"
},
"signatoryB": {
"_type": "reference",
"_ref": "jurisdiction-es"
},
"article15Terms": {
"exemptionDayLimit": 183,
"countingPeriod": "rolling_12_months",
"conditions": [
"Recipient is present in the host state for <= 183 days in any 12-month period commencing or ending in the fiscal year concerned",
"Remuneration is paid by, or on behalf of, an employer who is not a resident of the host state",
"Remuneration is not borne by a permanent establishment or fixed base which the employer has in the host state"
]
},
"legalHierarchyStatus": "supersedes_domestic",
"sourceTreatyUrl": "https://www.incometaxindia.gov.in/DTAA/Spain.pdf"
}
Example 2: Indian jurisdiction
JSON
{
"_id": "jurisdiction-in",
"_type": "jurisdiction",
"name": "India",
"code": "IN",
"taxYearCycle": "fiscal_year_apr_mar",
"domesticResidencyRule": {
"statutoryAct": "Income-tax Act, Section 6(1) (Residential Status) & Section 5/9 (Scope of Total Income)",
"daysLimit": 182,
"comparisonOperator": "greater_than_or_equal",
"windowType": "fiscal_year",
"territorialSourceRule": "An individual is a tax resident if present in India for >= 182 days during the financial year (1 April to 31 March), or >= 60 days if present for >= 365 days across the preceding 4 financial years. Residents and Ordinarily Residents (ROR) are subject to tax on worldwide income, while non-residents are taxed exclusively on income accrued, arising, or received in India under Section 5 and Section 9."
}
}
Sanity supports initial context out of the box, so when we built a database, it can use the GROQ mode to query the data at request time. But, this does not solve the fundamental problem with the RAG model that we just discussed, we need to ensure that there are no conflicts involved with the data that we are seeding and if there are, we need to specify which takes priority.
So, it was decided to move with Knowledge Bases which can process the data that we ingested first. It serves an index built from the data source that we provided, flags the conflicts found when builting that index, and with human-intervention it can be resolved, before the query stage even begins. This is especially usefull against law documents which can be often found conflicting. For example, here in our schema, we introduced a field in the bilateral treaty: legalHierarchyStatus which can indicate whether the treaty overrides domestic laws or it is subject to domestic GAAR (General Anti-Avoidance Rule) override
How I Used Sanity:
This would be a technical section, making some repeat over the intuition behind the earlier section, but please bear with me:
How I Used Sanity
1. Modeling Structured Legal Relationships in the Content Lake
Instead of treating legal tax codes and treaties as unstructured markdown chunks or raw PDFs, I modeled them in the Sanity Content Lake using two custom schema types:
-
jurisdiction: Stores domestic tax rules, residency day-count thresholds (daysLimit), statutory comparison operators (greater_than), and tax year cycle boundaries (such as Spain's calendar year vs. India's fiscal year). -
bilateralTreaty: Models international tax treaties as directed graph relationships between two signatory jurisdictions (signatoryAandsignatoryB), specifying Article 15 exemption conditions, counting windows (e.g., rolling 12-month periods), and statutory hierarchy status (supersedes_domestic).
2. Pointing Sanity Context to Build the Knowledge Base
To compile the Knowledge Base, I pointed Sanity Context directly at the Content Lake dataset via a GROQ-scoped source.
During the compilation build:
-
Topic Synthesis & Entry Compilation: Sanity Context transformed the discrete relational documents into synthesized topic entries (such as
residency/domestic_rules,dtaa/article_15,dtaa/treaty_inventory, andpe_risk). - Issue Detection & Standing Instructions: When compiling conflicting legal sources—specifically Spain's domestic territorial rule claiming Day-1 tax rights under IRNR Art. 13.1(c) versus bilateral treaty exemptions—Sanity Context surfaced a critical conflict in the Issues tab. I resolved this issue with a standing instruction: international bilateral treaties (DTAAs) supersede domestic statutory territorial taxes under Article 96 of the Spanish Constitution. This decision survived compiler rebuilds and permanently aligned all synthesized entries.
3. Exposing Tools via Sanity Context MCP
I configured a hosted Model Context Protocol (MCP) server endpoint in Sanity Manage operating in Knowledge Base mode, providing the AI agent in the Antigravity IDE with access to core retrieval tools:
-
initial_context: Called at the beginning of the arbitration session to inspect the Knowledge Base ID (kbMH6TgNzIIz) and discover the topic outline with its[core]path tags. -
knowledge_base_search: Used to perform keyword-based exploration across compiled paths when mapping cross-border treaty provisions. -
knowledge_base_read: Used to batch-read authoritative, fully cited entry paths (such asresidency/domestic_rules,dtaa/article_15, andpe_risk) in a single network round-trip.
4. What the Agent Did With the Retrieved Content
When presented with the triangular case (an Indian resident employed by a German GmbH working remotely in Spain), the agent executed deterministic multi-jurisdiction arbitration:
-
Evaluated Domestic Residency: Read
residency/domestic_rulesto calculate that the employee's 128-day stay split across two calendar years (78 days in 2026, 50 days in 2027) did not breach Spain's $>183$-day statutory residency threshold under LIRPF Art. 9.1(a). -
Resolved Treaty Supremacy: Read
dtaa/article_15and applied the standing instruction to override Spain's domestic Day-1 IRNR 24% withholding rule, granting a 100% personal income tax exemption under the India–Spain DTAA. -
Attributed Corporate PE Risk: Rather than conflating the employee's personal tax status with corporate enterprise exposure, the agent traversed to
pe_riskand evaluated the German employer under the Germany–Spain DTAA (Article 5). Because the employee engaged in on-the-ground commercial Statement of Work negotiations, the agent flagged a High Dependent Agent Permanent Establishment (DAPE) risk for the German GmbH.
Demo
Check out the demo at YouTube
Code
Check out the project on GitHub.
Sanity Project Details
-
Sanity Project ID:
1vdo75k2 -
Dataset:
production(Public) - Public Content Lake Query URL: [https://1vdo75k2.api.sanity.io/v2026-09-18/data/query/production?query=*[_type%20in%20[%22jurisdiction%22,%20%22bilateralTreaty%22]]]
Thanks,
MT
Top comments (0)