← All Field Notes
AI adoption / FIELD NOTESOCTOBER 2026

Your company wants to use AI. Where would I actually start?

If nobody at your company knows what an AI project should look like, I would start with the jobs people already do, not with a model shopping list.

I think a lot of companies are in an odd spot with AI right now. Employees have tried ChatGPT at home. Somebody in leadership has seen a demonstration. People agree there is probably something useful here, but nobody can explain what the first real project should be.

That doesn't bother me. You don't need to understand model hosting, vector databases or agents to have a productive conversation about AI. You do need to understand the work your company does. That is where I'd start.

Ask people what they're tired of doing

Not which AI tool they want. What are the annoying jobs? Where do people spend an hour finding an answer in an old document? Which requests arrive in a shared inbox and need to be sorted manually? What information gets copied from a PDF into a spreadsheet and checked again by someone else?

I'd talk to the people actually doing that work. They'll usually give you a better list than a management meeting. And I'd look for something frequent enough to matter, small enough to test, and simple enough that the result can be checked. The first AI project shouldn't be something where an incorrect answer could quietly do serious damage.

An internal document assistant is a reasonable example. Not because every company needs one, but because you can test it against questions employees already ask. Maybe the system finds an answer, links the original document and saves a few minutes. Maybe your documents are so disorganized that search is the real problem. Both outcomes are useful to learn.

Don't start by buying a server

There's a temptation to make AI adoption into an infrastructure project on day one. I work on infrastructure, so I understand why. The equipment is tangible. You can get quotes, pick a model and point to a machine doing something.

But for a company that hasn't used AI, I'd normally test a narrow use case with a hosted model first, provided its data handling meets the business's requirements. Private hosting can make sense later for sensitive workloads, control or steady usage. It isn't automatically safer just because the server is in your building, and it isn't automatically cheaper either.

I'd set clear rules for what data may go into the pilot, choose a few real examples and measure whether staff would use the results. Someone should review the output, particularly if it could affect a customer or a business record. An attractive demo is not the same thing as a dependable process.

Connect it to work people already do

Let's say the pilot helps categorize requests arriving by email. Great. The next question is whether people still need to copy the category into a separate system. If they do, you haven't finished the job. The useful version might send a suggested classification into the ticketing tool, wait for approval and record what happened.

That's where the engineering work often starts. Accounts, APIs, permissions, error handling, monitoring. None of those are glamorous, but they're what turns an AI experiment into something the company can use on a Tuesday when nobody from the project team is in the room.

I'd rather see a business get one modest workflow working end to end than launch ten chatbots that everybody forgets about. You can build on a good first project. And if it turns out that ordinary automation is a better fit than AI, that's a useful answer too.

If your team wants to explore AI but hasn't picked a project, that's work we take on at Layer Frame. We can help choose a starting point, build the pilot and work through the integration if it proves useful.

Talk about getting started ↗