For Alaska processors, tenders & fishing operations
Seafood operations surge from a skeleton crew to hundreds of people and back, with landings data, crew settlements, and regulatory reporting all compressed into the same window. We build agents that carry the administrative surge so your people can run the plant.
Built in Anchorage · we publish our source code · no long-term lock-in
Written by Kristian Baer, Northtek · Anchorage, Alaska · Updated 2026-08-21
The short answer
It absorbs the administrative surge. A processor goes from a dozen year-round staff to several hundred seasonal workers in a few weeks, and every one of them generates hiring documents, housing assignments, and payroll. At the same time landings data, fish tickets, and settlement calculations pile up against regulatory deadlines. None of that work requires judgment, all of it is deadline-bound, and hiring administrative staff for eleven weeks is difficult and expensive. Agents handle document intake, reconciliation, and drafting, and your year-round people handle the decisions. The other durable gain is off-season: buyer inquiries and specification requests get answered in hours instead of days because the product and certification data is finally searchable.
The operating reality
Bristol Bay, Dutch Harbor, Kodiak, and the Southeast fisheries all share the same shape: enormous throughput in a short window, a workforce that turns over completely, and reporting that does not care that you were busy.
Hundreds of seasonal hires means hundreds of I-9s, tax forms, housing assignments, and safety acknowledgements, chased by a small year-round team while the plant is running.
Fish tickets feed settlements, taxes, and regulatory reporting. An error found in October is far more expensive than the same error caught the day of the landing.
Share calculations, deductions, advances, and price adjustments are error-prone and highly visible. A settlement mistake is a crew relationship problem, not just an accounting one.
Specifications, certifications, chain of custody, and lot traceability requests arrive constantly, and the answers live in documents nobody can search quickly.
Six workflows we build
Split between in-season surge relief and the off-season work that keeps buyers happy.
01
02
03
04
05
06
First 30 days
Nobody should be deploying software during a Bristol Bay run. The build happens between November and March, and the season is the test.
We take last season’s actual data and trace where reconciliation broke, where settlements were corrected, and how many hires arrived with incomplete files.
The agents run against real prior-season data, which means we can measure accuracy on known outcomes before a single fish is landed.
Deployment happens weeks before the run, with your existing process still fully available. If anything degrades under load, you fall back without drama.
What you own at day 30
A reconciliation and settlement agent tested against your own prior season, an accuracy report on known outcomes, the source code and configuration, and a documented manual fallback your plant manager can trigger without calling us.
What we built, in the open
A season is the least forgiving deployment environment there is: peak throughput, a workforce that has never seen the system, and no second attempt. What makes that survivable is not clever engineering during the run, it is having measured the thing against last year's real data months earlier.
A verification gate that checks a reconciled figure against the ticket behind it. On landings data, catching a mismatch the day of delivery is worth more than any amount of downstream reporting.
Our own memory server, offline mode included. Dutch Harbor, Naknek, and a tender at anchor are normal cases, and a system that assumes connectivity is a system that fails during the run.
A language built so an agent's steps are readable. When a crew member questions a settlement, the calculation path is something a person can walk through with them.
Public, with the benchmark harness. It is why we will quote you an accuracy figure from your own prior season instead of an assurance.
Scope, stated up front
A season is unforgiving, so the honest limits matter more here than the feature list. Three of them.
It will not resolve a disputed landing
When a captain and a plant disagree about a weight, that is a conversation between people. The agent makes the evidence available faster, which usually shortens the conversation.
It does not set prices
Ex-vessel price decisions are commercial and relational. We build the calculation and the statement, not the number at the top.
We do not deploy mid-run
If you come to us in June, we build against the season in progress and go live before the next one. Your season is the one thing that cannot be repeated, and we protect it rather than gamble with it.
Where your data goes
Landings and settlement data are financial records with a regulatory tail. Four commitments we put in the agreement.
We work alongside it. The reconciliation and exception detection happen on your side, against the data going in and the records coming out. We are not replacing a state reporting system and we would not propose to.
The eleven weeks are exactly why it is. Compression is what makes the administrative load expensive: the same volume spread over a year is absorbable, and concentrated into a run it is not. A large processor with hundreds of seasonal hires and thousands of landings gets the biggest return, and a smaller operation gets a scoped-down build sized to its volume rather than the full stack.
That is the point of building it. The statement shows the calculation path in plain language: landings, prices, deductions, advances, and the resulting share. Settlement disputes are usually about not understanding the number rather than the number being wrong.
Everything queues locally and syncs when a connection is available. Dutch Harbor, Naknek, and a tender at anchor are all normal cases here, not edge cases, and we test them deliberately.
Right after the season ends. That gives us the data from the season just finished to build and test against, and months of margin before the next run. A build that starts in April is a build that will not be trusted in June.
Yes. Catcher-processors carry the same settlement and reporting load in a smaller footprint, and the build scales down cleanly. For a single boat we scope a lighter version - settlement statements and regulatory prep - rather than the full reconciliation stack, so the cost matches the operation.
We build against data you already have and go live before the run. Sixty minutes to find out whether it is worth doing at all.
Anchorage, Alaska · info@northtek.io · (907) 903-4353