Gil Neto is a senior software engineer with 12 years' experience, based in Lisbon, Portugal. He works as a Founder-Engineer, building and operating B2B utilities solo from infrastructure to UI, and as a senior software engineer on AI products, building LLM-backed systems for other people. His current focus is the memory and knowledge layer that LLM systems run on: how an agent captures what it learns, where that knowledge is stored, how it is retrieved, and how staleness is detected. He runs a second-brain system on those rules daily, and builds Kelaro (accounting-automation SaaS) and Koa (deterministic document-extraction engine).

Does Gil Neto work on AI and LLM products?

Yes. Gil Neto works as a senior software engineer on AI products, building LLM-backed systems where the model handles judgment and deterministic code handles correctness. That covers agent memory and persistent knowledge architecture, LLM application architecture, retrieval-augmented generation, model evaluation and eval harnesses as release gates, agent orchestration, and document extraction. He is available for fractional build engagements on bank-data and accounting pipelines, based in Lisbon and remote across EU timezones.

What AI systems has Gil Neto built?

Koa, a deterministic document-extraction engine built as the deliberate alternative to vision-LLM extraction for bank statements: it forces balances to reconcile and refuses loudly rather than returning a plausible total. Kelaro's LLM-backed pipeline, running on durable Temporal workflows with the model kept out of the arithmetic. An agentic development pipeline called midas, which resolves every open decision before anything is specified, built on top of Matt Pocock's wayfinder model. A second-brain system giving an LLM agent persistent long-term memory: a markdown knowledge base the agent reads and writes, with capture, routing and checkpointing enforced by lifecycle hooks rather than prompts, retrieval split between generated indexes for state and vector search for specific facts, and a scored nightly eval that detects when the index has gone stale. Earlier, the LLM-integration layer at Opplane between 2021 and 2026.

What kind of work is Gil Neto open to?

Fractional build engagements on bank-data and accounting pipelines: architecture, the first working version, and a handover. Remote-first across EU timezones, based in Lisbon.

What is Gil Neto's primary tech stack?

TypeScript, Python, and SQL as primary languages. Next.js, React, Node.js, Nest.js, Fastify, Flask, and Temporal for runtime. Docker, Nginx, PostgreSQL, pgvector, MongoDB, Redis, BullMQ, Kafka on AWS and GCP for infrastructure. Integrations with Stripe, OAuth 2.0, Open Banking (PSD2), Brevo, and Umami.

What is Gil Neto's technical philosophy?

Memory as infrastructure: an agent that forgets is a demo, so capture, routing and evaluation are enforced by the harness while judgment stays the model's job. Infrastructure-first: own the boundary from DNS to UI, everything containerized and reproducible. AI-augmented execution: leverage coding agents to eliminate boilerplate and focus on architecture and business logic.

What products has Gil Neto shipped?

Kelaro (kelaro.io) — accounting-automation SaaS in closed beta with one active pilot in Portugal (a chartered accountant), Netherlands pending; Koa — a deterministic PDF bank-statement extraction engine powering Kelaro, built as the alternative to vision-LLM extraction; and a second-brain memory system for an LLM agent, running daily and documented publicly. Previously: Lead Engineer at Opplane driving monolith-to-microservices migration and LLM-integration pipelines; Front-end Lead at Glartek shipping the core industrial-IoT product.

Where is Gil Neto based and what languages does he speak?

Based in Lisbon, Portugal. Native Portuguese, proficient English, elementary Spanish. Available for fractional build work on bank-data and accounting pipelines, across EU timezones.

crypto accounting mica reconciliation

Three exchanges died this year. The mess lands on accountants

September 29, 2026 · Gil Neto

Three mid-tier crypto exchanges shut down in 2026. AscendEX stopped operating on 1 July. BitMEX announced its closure on 23 July and shut on 23 September. CoinEx is winding down in steps: it set spot trading to end on 29 September, with withdrawals staying open until 22 December. By mid-year, RootData’s tracker counted 99 crypto projects that had died this year, but those three are the ones that matter here, because people used them like accounts.

Most of the coverage stops at the closure. Who lost access and how long the withdrawal window is. That’s the front office. I want to write about the back office, because that’s where I spend my time: I build a tool that takes a small accounting practice’s bank data and puts it into the spreadsheet the practice already runs on. I looked hard at crypto as a source for it in August, and I decided not to build it. The reasons I said no are the same reasons this is going to hurt someone in about a year.

What actually closed them

The easy story is “MiCA killed them”. It’s close, but the date people quote is wrong. MiCA started applying to crypto-asset service providers on 30 December 2024. The 1 July 2026 date that keeps showing up is only the outer limit of the grandfathering window (Article 143(3)), the grace period for providers already operating under national rules, and several member states ended it earlier than that.

So, the regulation didn’t arrive in July. It arrived eighteen months earlier, and July was when the last excuse ran out. For a mid-tier venue the choice was a full licence, with the compliance cost that comes with it, or leave. Three of them left.

The tax year outlives the venue

Here is the part that makes it an accounting problem and not a news story.

The EU’s crypto reporting directive (DAC8) has been in force since 1 January 2026. Exchanges collect data through 2026 and file the first reports between January and September 2027. So 2026 is the first year in which a European’s crypto activity becomes visible to their tax authority as a matter of routine.

Put the two timelines next to each other. A client traded on one of these exchanges in the first half of 2026. Their accountant sees the numbers in spring 2027, maybe prompted by a letter from the tax authority, which by then has data the client never looked at. By then the venue that produced the history may not exist anymore, and the client may not be able to log back in to re-download the statement. Whatever the client exported before that point is now the only record, and I’d guess most clients won’t export anything until someone asks them to.

Why an exchange export is worse than a bank statement

When I looked at crypto for my own tool, I expected it to be another source. Bank statement in, rows out. It isn’t, for three reasons.

An exchange export is incomplete by design. It shows what happened inside that venue. Internal transfers, failed transactions and staking rewards show up inconsistently or not at all, depending on the venue and on which export you picked.
Cost basis lives across venues. Bought on one exchange, moved to a wallet, sold on another. No single exchange knows what the asset cost. The number the tax return actually needs is stitched together from several sources, and one of those sources just disappeared.
There is no authoritative statement to check against. With a bank, I can take the opening balance, add the transactions and check that I land on the closing balance the bank printed. If it doesn’t tie out, something is missing and I know it. With an exchange, the export IS the unreliable object. There’s nothing independent to reconcile it against, and after closure there never will be.

The third one is the one that bothers me most. A bank reconciliation fails loudly when rows are missing. An exchange history just looks shorter.

What I’d do this week, if I had a client on one of them

None of this needs a product. It needs a checklist, and it needs to happen soon: CoinEx withdrawals close on 22 December. After that, whatever is left moves into custody at a monthly fee of 5% of the original balance, and claims close in August 2028. BitMEX and AscendEX have given no guaranteed end date for theirs, which is not reassuring.

Export everything the venue still offers: trade history, deposits, withdrawals, fees and any staking or earn records. Separate files are fine, keep all of them.
Save the final balance screen (a screenshot is fine) the day before the last withdrawal. It’s the closest thing to a closing statement you’re going to get.
Note where every withdrawal went. That address or account is where the cost basis continues, and it’s the thread the accountant will need to pull next year.
Convert to fiat at the transaction date, and keep the rate you used next to each row. Doing that in 2027 from memory is much harder.
Check it yourself, once: deposits minus withdrawals, plus or minus trades and fees, should land on zero after the final withdrawal. If it doesn’t, something is missing, and you can still go back and look now. Access to any of these three could tighten without much more warning than they’ve already given.

Why I’m not building this

I’d argue the demand is real and it has a date on it. Even so, it’s the wrong thing for me to build right now. It expires by design (CoinEx closes withdrawals on 22 December, and the other two could follow). The buyer is a crypto holder and not the accountant I sell to, and cost basis across venues is a different product from the one I’m building. The tools that already do cost basis are mature and cheap.

So, I’m writing it down instead. If you’re an accountant with a client on AscendEX, BitMEX or CoinEx, send them the checklist above now, while the withdrawal window is still open.