How one operator taught AI to run his business

Eldar Bar-Or, owner of 603 Auto Salvage, built agents that evaluate vehicles, make offers, manage marketing, and close deals. The hard part was teaching them how the business actually works.

A few weeks ago, I met Eldar Bar-Or, who is using AI in one of the most impressive ways I’ve encountered.

Eldar is not a software engineer, and he does not run a technology startup. He owns and operates 603 Auto Salvage, an automotive recycling business.

The company buys vehicles that have been totaled, have major mechanical problems, or are too old to sell through traditional channels. Depending on the vehicle, 603 Auto Salvage might dismantle it and sell the parts, resell it through another channel, or recycle it for metal.

Eldar has been doing this for more than a decade. Over that time, he built a substantial operation with several storage lots, hundreds of vehicles, major investments in SEO and online advertising, and a team handling incoming inquiries.

The basic workflow was straightforward:

• A seller found the business through Google, Facebook, the company’s website, or another channel.

• An employee collected information about the vehicle.

• The employee evaluated it and made an offer.

• The team followed up, negotiated, and tried to close the deal.

• If the seller accepted, the company coordinated the next steps.

Then, last December, Eldar started experimenting with OpenClaw.

He had no coding experience. Within a few months, he had rebuilt much of the company’s digital operation around AI agents.

From answering questions to closing transactions

Calling what Eldar built a collection of chatbots would undersell it.

Prospective sellers can contact 603 Auto Salvage through its website, Facebook, third-party platforms, and the phone. In many cases, an AI agent handles most or all of the interaction.

The agents collect vehicle information, ask follow-up questions, evaluate the opportunity, make an offer, answer objections, and continue the conversation until the transaction is closed. The company even has an AI voice agent that can answer incoming calls and provide an offer during the conversation.

The automation extends beyond sales. The system also helps manage online advertising, generate SEO content, follow up with leads, update internal systems, and track results across channels.

The system currently uses Claude Opus 4.8, and Eldar’s AI bill is approximately $10,000 per month.

That sounds expensive when described as a software subscription. It looks different when compared with the cost of running a sales, marketing, engineering, and call-center function that operates around the clock.

New inquiries do not wait for someone to start a shift. Conversations continue at night, on weekends, and while Eldar is asleep.

The agents changed the jobs

603 Auto Salvage still hires employees. The difference is what those employees are being hired to do.

Some oversee the agents’ work, review unusual outcomes, and identify where the system needs to improve. Others step into sales conversations that are currently too complex for the agents to handle reliably.

That “currently” matters.

The boundary between what the agents can manage and what requires a person keeps moving. As Eldar finds new edge cases, improves the instructions, and changes the workflow, more tasks move from the human queue into the automated one.

People are still needed to:

• Supervise agent performance

• Handle complicated transactions

• Operate machinery in the vehicle lots

• Move vehicles and remove parts

• Inspect physical inventory

• Confirm that listed parts are actually available

This is not a business without people. It is a business where people spend less time collecting the same information and chasing the same leads, and more time managing exceptions, supervising automation, and performing physical work.

A photograph can answer questions too

One of the most interesting challenges was figuring out how to evaluate a vehicle without forcing the seller through a long questionnaire.

Traditionally, an employee might ask whether there is visible body damage, whether important components are missing, whether the vehicle has been partially dismantled, or whether a specific valuable part is still present.

Every extra question creates work for the seller. Some people do not know the answer. Others lose patience and abandon the process.

Eldar realized that photographs could provide some of this information more efficiently.

Instead of relying only on manually entered details, the system can request photos and use them as part of the evaluation. The agent can inspect the images, identify relevant details, and determine which questions may already have been answered visually.

This saves time for the seller and may improve the quality of the offer. But it also creates new process questions.

Which details can be inferred reliably from a photo? Which still require confirmation? What happens when an image is blurry or incomplete? How should the agent distinguish between something it can see and something it is merely guessing?

Eldar had to define which visual signals matter, how they affect the evaluation, and when the agent should request another image or escalate the case.

One seller does not always mean one vehicle

Another complication appeared when the system encountered sellers offering several vehicles at once.

An individual might submit one car. An auto shop, towing company, or another business might want to sell three, four, or five vehicles in one transaction.

The agent must collect a separate set of details for each vehicle while maintaining the context of the overall deal. It needs to understand which photo, title, condition report, and offer belongs to which car.

It also needs to avoid mixing information between vehicles. A missing engine in one car cannot affect the valuation of another. A photo sent halfway through the conversation needs to be connected to the correct record. Negotiations may happen at both the individual-vehicle level and the package level.

Eldar had to teach the system to:

• Create a distinct record for every vehicle

• Associate each answer and image with the right record

• Track missing information separately

• Generate individual valuations

• Understand whether the seller is negotiating one offer or the full package

• Preserve the relationship between each vehicle and the combined transaction

This looks like a narrow edge case, but it exposes a broader challenge.

Real business conversations are not clean forms. People change subjects, provide information out of order, correct themselves, send several photos at once, and assume the other person understands what they mean.

The agent needs more than language comprehension. It needs a structured model of the transaction.

The model was not the hard part

It is tempting to tell this story as evidence that powerful models can automate almost anything.

Give someone access to OpenClaw and Claude, and the business runs itself.

That is not what happened.

Eldar spent months redesigning processes, testing conversations, identifying bugs, connecting systems, changing call scripts, and figuring out where the agents made poor decisions.

More importantly, he had to explain how his business works.

He had to define:

• What makes a vehicle worth buying

• Which information is required before making an offer

• Which details can be inferred from a photo

• How vehicle condition should affect the price

• When the agent should negotiate or stop

• Which cases need human review

• How multiple vehicles should be represented in one deal

• How inventory affects the value of another vehicle or part

• Which system contains the authoritative information

After more than a decade in the industry, many of these decisions were intuitive to Eldar. They were embedded in employee training, scripts, spreadsheets, and experience.

The agents could not rely on intuition. The logic had to be made explicit.

Claude could generate software, and OpenClaw could give agents access to tools. Neither could independently determine how to value a damaged vehicle, structure a multi-car transaction, or decide whether a photograph contained enough evidence to skip a question.

Eldar had to supply the meaning behind the workflow.

In other words, he had to build a semantic model of his business.

Autonomy required a single source of truth

As Eldar added agents, he ran into another major problem. The company’s information lived across several disconnected systems.

One contained incoming inquiries. Another contained vehicle or parts inventory. Other tools supported calls, advertising, offers, or operations.

Humans are surprisingly good at working around this fragmentation. An experienced employee might know that one field is outdated, another system has the real number, and a particular status means something different from what it appears to mean.

Agents do not automatically know any of that.

Eldar rearchitected the operation around a single database. He also built a custom web application for managing the business and monitoring the agents.

This was not just a software cleanup project. It was a prerequisite for autonomy.

An agent cannot make a reliable offer if it does not know which information is authoritative. It cannot sell a part if the inventory record is disconnected from what is actually in the lot. It cannot coordinate Facebook, website, and phone conversations if each channel has a different understanding of the customer.

We see the same problem in enterprise analytics. A company wants an AI analyst, but the AI encounters conflicting definitions, undocumented business logic, and multiple systems claiming to contain the truth.

Before the agents could operate the business, the business had to become legible to them.

Autonomous does not mean unobserved

Eldar did not automate the process and walk away.

His custom application tracks agent activity, business performance, inventory, conversations, logs, call scripts, and errors. He effectively built his own version of Gong so he could review calls and understand why conversations succeeded or failed.

That monitoring system may be the most important thing he built.

We have previously written about how GenAI is consistently inconsistent and how we approach testing Solid’s Chat. When software is probabilistic, logs and performance metrics are not secondary engineering tools. They are part of the operating system.

Eldar needs to know where an agent misunderstood a customer, why it arrived at a particular offer, which scripts produce better results, which cases get escalated, and whether a model or process change improved performance.

A failed conversation is not only a lost lead. It is also evaluation data.

He can inspect the failure, identify the missing rule or context, and improve the system. He is effectively building evals from the real edge cases of his business.

Zero coding experience does not mean zero expertise

The most surprising detail is that Eldar had never written code before.

But focusing on his lack of software experience misses what he did know.

He knew what a good opportunity looked like. He understood how a vehicle’s condition should affect an offer. He knew which questions sellers ask, where deals get stuck, and which mistakes create losses.

The AI supplied much of the software engineering. Eldar supplied the business context.

Without his knowledge, the agents might have produced impressive demos. They could have answered a few messages or generated generic SEO articles. They would not have been able to run a real operation.

This is semantic engineering in the wild.

It is the work of converting implicit organizational knowledge into entities, relationships, instructions, constraints, and evaluation criteria that machines can use.

In this case, those entities include sellers, vehicles, parts, photographs, offers, conversations, and multi-vehicle transactions. The relationships matter just as much as the individual data points.

A photo must belong to the correct vehicle. A vehicle must belong to the correct transaction. An offer must reflect the right condition and inventory context. A human escalation must preserve everything the agent has already learned.

The principle is the same whether you are building an AI analyst, a data agent, or an automotive recycling operation.

The AI needs more than access to the company’s tools. It needs to understand what the information means, how it relates, and how the business uses it to make decisions.

Business logic is becoming the bottleneck

For years, building custom business software required a long translation process.

An operator described the business to a product manager. The product manager wrote requirements. Designers created interfaces. Engineers implemented the logic. Months later, the operator received software that hopefully resembled what they had requested.

That translation layer is becoming dramatically smaller.

Eldar could explain a process to the AI, test what it built, identify what was wrong, and continue iterating. He created integrations, dashboards, agents, monitoring systems, and internal applications without becoming a traditional software engineer.

The code was no longer the primary bottleneck.

The bottleneck was his ability to describe the business clearly enough.

That is the part enterprises should pay attention to. Most companies will have access to increasingly capable models and agent frameworks. Access to the technology alone will not create a trustworthy operation.

The advantage will belong to companies that can make their business logic legible to machines.

Eldar turned more than a decade of experience at 603 Auto Salvage into data structures, instructions, tools, and feedback loops that AI agents could use.

The result is not a business without people. It is a business where people supervise a growing system of automated work, handle the cases that remain too difficult, and improve the agents based on what happens in production.

Eldar taught the AI how his business works.

Now the system keeps working while he sleeps.