The first version of an AI feature is always a function that calls a model. The second version is the same function in a different module. By the fifth, the API key is in five places, nobody can say what the month cost, and switching provider means touching every one of them.
Vectiq Field's AI layer is nine services - agent, LLM gateway, RAG, embedding, vector, knowledge graph, predict, recommend and vision - and the gateway exists specifically so that the fifth version never happens.
What the gateway owns
Three things, and only these three:
- Model choice. Which provider and which model answers a given kind of request. Changing it is a configuration change in one service, not a code change in nine.
- Credentials. The API key lives in exactly one place. A service that wants a completion asks the gateway; it never holds a key it could leak in a log line or a stack trace.
- Cost. Every call is attributed, so "what did AI cost us last month, and for which farm" is a query rather than a conversation with the finance team.
What it deliberately does not own is prompt logic. Each service knows its own domain and writes its own prompts; a gateway that also templates prompts becomes the place every team has to queue at.
Why nine and not one
Splitting services has a real cost - more deployables, more failure modes - so the split has to earn it. Here it does, on two grounds.
Hardware. The vision service classifies leaf photographs and wants a GPU. The RAG service assembles context from PostgreSQL and wants none. Fused into one process, the whole thing is scheduled onto GPU nodes and most of the capacity is wasted on retrieval. Split, they scale on their own curves.
Deployment scope. A farm that bought disease detection and nothing else should not be running a knowledge-graph service. Nine deployables means the smallest useful installation is genuinely small.
Retrieval over this farm, not over agriculture
The distinction that makes the assistant worth anything: general agronomy knowledge is a commodity, and a model already has it. What it does not have is what was applied to block seven in March, at what rate, and what the yield was in July.
The RAG service retrieves from the farm's own activity log, treatment records and sensor streams. The knowledge graph gives it the structure that plain retrieval misses - that this block, this crop, this input and this outcome are connected - so a question about a field can walk to the inputs that touched it rather than hoping the right paragraph is nearby in vector space.
If work is not logged, or is logged three days later from memory, the assistant answers confidently from bad data. This is the unglamorous dependency: the offline field-logging app is not a nice extra next to the AI layer, it is the thing that makes the AI layer worth deploying.
Prediction and recommendation are not the same service
Prediction estimates what will happen - yield, risk. Recommendation says what to do about it - irrigate now, treat this block.
Keeping them apart is not tidiness. A prediction can be evaluated against what actually happened, so its error is measurable and it improves. A recommendation is evaluated against a decision a human made, which is a different and much weaker signal. Merging them hides the one number you can honestly report.
What we would tell someone starting this
Build the gateway before the second AI feature, not after the fifth. It is a small service and it is almost entirely boilerplate - and every month you delay it, the cost of introducing it grows by one more place where a key is hardcoded.