The Enzyme That Wouldn't Fold

A closed-loop computational protein-design story.

Some proteins simply refuse to cooperate. This is the story of one of them — a therapeutically important enzyme that, for more than a decade, could not be produced in a soluble, active form in the workhorse bacterium Escherichia coli. It expressed, but it collapsed into dense, insoluble aggregates — inclusion bodies — that resisted every classical rescue: molecular chaperones, solubility-enhancing fusion partners, codon optimization, gentler induction. Nothing worked. Each new attempt cost weeks of work and real money, and each ended the same way.

So we stopped guessing, and asked the computer why.

Asking the structure why

The first question was the most basic: what does this protein actually look like when it tries to fold alone? Modern structure prediction (AlphaFold) gave a striking answer. Compared with a closely related enzyme that folds cleanly in E. coli, our problem protein was predicted with markedly lower confidence — and the low-confidence regions were not random. They clustered in the enzyme's functional heart.

The interpretation was almost poetic: this enzyme evolved to fold around its natural molecular partner. With the partner present, the structure snaps into place. Alone, over-produced in a bacterium that lacks the eukaryotic folding machinery it grew up with, the functional core never fully sets — and a half-folded protein is a sticky protein.

That single insight reframed fifteen years of frustration. The failures of chaperones and fusion tags were not bad luck; they were the predictable result of fighting a fold problem with folding-help tools. The instability is intrinsic. You cannot chaperone your way out of it.

Reading the surface

If the deepest cause could not be fixed without breaking the enzyme's function, what could be fixed? We turned to the protein's surface. Two liabilities stood out from a structural aggregation analysis:

• an unusually large patch of exposed greasy (hydrophobic) residues — a classic magnet for aggregation under over-expression; and
• a set of reactive cysteines that, once the protein starts to misfold and clump, can cross-link neighbouring molecules together, welding the aggregate shut and making it stubbornly insoluble.

Neither of these is the root cause. But both are fixable, and both make a bad situation worse.

Designing with guardrails

Here is where it becomes easy to do harm. This enzyme's surface is not decoration — much of it is the very machinery it uses to grip its partner and do its job. Naively "cleaning up" the greasy surface would smooth away function along with the aggregation.

So we drew a hard line. Using the enzyme's known complex structure, we separated its surface into two categories: residues that face the outside world in both the lone protein and the working complex (true, safe-to-edit surface), and residues that only look exposed in isolation but are actually buried against the partner when the enzyme is at work (untouchable). We then let a generative sequence-design model repack only the genuinely safe surface toward more soluble chemistry — never the catalytic residues, never the partner-binding interface, never the parts that make the enzyme an enzyme.

An honest scorecard

The temptation in computational design is to produce a confident-looking answer and rush it to the bench. We did the opposite. Every candidate had to clear an evidence gate built from independent signals:

• a solubility oracle that we first validated — it correctly told apart our known-soluble control from the known-insoluble target before we trusted it on anything new;
• the generative model's own soluble-sequence score; and
• a fold check: does the redesigned protein still fold as well as the original?

Only candidates that improved on every axis — more soluble by the oracle, favoured by the design model, and still folded — advanced. The best of them scored more soluble than our soluble benchmark, while leaving the fold and the catalytic core intact.

The philosophy: evidence before the bench

The point of this project was never a single sequence. It was a way of working. When a wet-lab experiment costs months and thousands of dollars, the job of computation is to make sure you spend that money on your best-justified idea — not your first idea. So we built a complete, cross-checked in-silico dossier: a diagnosis of why, a set of designs constrained to never break function, and a ranked scorecard where every prediction is validated against a known reference.

We also wrote down, honestly, what computation cannot promise. The deepest cause of this enzyme's trouble — a fold that leans on its natural partner — is not something a surface edit can erase. So we expect a meaningful improvement, quite possibly not a total cure. Computation narrows the odds and tells you where to look; the bench still decides.

What's next

The designed candidates are on their way to the laboratory now. In a couple of months we will know how the predictions held up — and, either way, that result flows straight back into the models. That is the closed loop: design, build, test, and learn, with every round better informed than the last.

It is a good way to do science. And for a protein that spent fifteen years saying no, it is the most promising maybe we have had.

---

This article describes our computational methodology and design philosophy. It intentionally omits the target's identity, sequences, and specific engineered changes. Prepared with the NextELN AI Lab Assistant and scientifically reviewed by the NextELN science team, Excellgen, Inc. Status: research preview — computational predictions are hypotheses that require experimental validation.